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.
More Planning Details For GTK4 & Beyond
Collapse
X
-
Originally posted by boxie View PostTo 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.
Comment
-
-
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)...
Comment
-
-
Originally posted by boxie View PostTo 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.
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).
Comment
-
-
Originally posted by starshipeleven View PostIt'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).
Definitions:
Stable - It won't break
Feature complete - Nothing else needs to be addedLast edited by Sethox; 15 June 2016, 04:33 AM.
Comment
-
-
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?
Comment
-
-
Originally posted by dkasak View PostI 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?
Comment
-
-
Originally posted by boxie View PostTo 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.
Comment
-
Comment