More Planning Details For GTK4 & Beyond

[Luke]

At least if this works out it should avoid fed-up project devs ever having to fork GTK2 or a single, chosen and then stable version of GTK3.

[MaxToTheMax]

To me it seems "The developers want to play with the new shiny and don't want to touch the old stuff anymore - so we call it stable and never touch it again unless we really, really have to".

I hope this is not the case.

This is a problem why? It's exactly the appropriate course of action for anyone who maintains a popular dependency but also wants to do significant new development.

[Emdek]

Meh, perhaps they want to get rid off proprietary (and FOSS projects that aren't shipped by distributions) applications that use GTK? :-D
Breaking ABI in "stable" release stream is similar to Linux kernel, which requires new releases of proprietary drivers to support latest changes.
Anyway, it's abuse of version scheme (perhaps even worse than Chrome and Firefox do, bumping major number for no good reason), if they are going to have tens of beta releases, then they should call them that way.
Qt manages to both gradually extend APIs and keep ABI compatibility (AFAIR there was one minor exception in 5.4.1, fixed in next patch release).
Also, targeting specific GTK version is kind of like situation under Windows, where their redist DLLs for applications built with VS 2015 won't satisfy these built with VS 2013 (and now they even completely renamed one of them plus introduced myriad of DLLs needed to run them on Windows 7)...

[shmerl]

It's not enough they caused a horrible mess with GTK 3.20 recently (Firefox scroll bars are still broken for me until now with gnome-breeze), so now they plan to do it again?

[starshipeleven]

To me it seems "The developers want to play with the new shiny and don't want to touch the old stuff anymore - so we call it stable and never touch it again unless we really, really have to". I hope this is not the case.

It's more like "developers are fed up with shit that changes every month so whatever works now gets declared stable and we will keep it on life support so real world can use it while we move on to new shit that changes every month none will give a fuck about for the next decade".

That's how "stable" works. You stop adding features, and just fix bugs (backported or reported or otherwise). The "instability" in this case is the fact that they are breaking compatibility every month, not that GTK3 is unstable per-se (although changing things every month isn't really helping).

[Sethox]

It's more like "developers are fed up with shit that changes every month so whatever works now gets declared stable and we will keep it on life support so real world can use it while we move on to new shit that changes every month none will give a fuck about for the next decade".

That's how "stable" works. You stop adding features, and just fix bugs (backported or reported or otherwise). The "instability" in this case is the fact that they are breaking compatibility every month, not that GTK3 is unstable per-se (although changing things every month isn't really helping).

Doesn't a word for that exist already, FEATURE COMPLETE. To blur stable with feature complete is complete nonsensical.
Definitions:
Stable - It won't break
Feature complete - Nothing else needs to be added

[starshipeleven]

Doesn't a word for that exist already, FEATURE COMPLETE.

"feature complete" in anything but the simplest program is usually unattainable, a more realistic limit is "all crucial features are implemented and work decently".

[dkasak]

I wonder how many posts above are from people who actually develop with GTK+3. I've been developing with GTK+2 since about 15 years ago, and with GTK+3 since about 3 years ago, and I've *never* *EVER* had issues with API stability. I've written 'form' and 'datasheet' classes using both GTK+2 and GTK+3, and written a bunch of database-centric apps, including an ETL framework with a nice GTK+3 GUI. I use quite a bit of the functionality available, and create custom cell renderers in the datasheet class.

What I *think* people are whinging about is the theming subsystem, which admittedly is changing quite rapidly. But theming is not a core part of GTK+3, and not a part of the "API". Maybe someone would like to share some examples of API changes that they've actually encountered?

[bug77]

I wonder how many posts above are from people who actually develop with GTK+3. I've been developing with GTK+2 since about 15 years ago, and with GTK+3 since about 3 years ago, and I've *never* *EVER* had issues with API stability. I've written 'form' and 'datasheet' classes using both GTK+2 and GTK+3, and written a bunch of database-centric apps, including an ETL framework with a nice GTK+3 GUI. I use quite a bit of the functionality available, and create custom cell renderers in the datasheet class.

What I *think* people are whinging about is the theming subsystem, which admittedly is changing quite rapidly. But theming is not a core part of GTK+3, and not a part of the "API". Maybe someone would like to share some examples of API changes that they've actually encountered?

Oh, good. So theming can continue being the mess that it currently is. I'm glad we got that out of the way.

[justmy2cents]

To me it seems "The developers want to play with the new shiny and don't want to touch the old stuff anymore - so we call it stable and never touch it again unless we really, really have to".

I hope this is not the case.

if you look at gtk development, it is more like a case of dropping out shitty ideas as fast as possible and keep evolving on good ones. gtk3 has evolved to really nice toolkit exactly because of that. only problem is that for anyone needing stable there is nowhere to turn