… and that’s OK.
Please note that this blog post is very old, and not an accurate reflection of the current state of versioning in GTK.
This morning in Toronto, many GNOME developers met to kick off the GTK hackfest.
The first topic that we discussed was how to deal with a problem that we have had for some time: the desire to create a modern toolkit with new features vs. the need to keep a stable API. Gtk 3 has seen a very rapid pace of development over its lifetime and we have a much better toolkit than we started out with. Unfortunately, this has often come with the cost of less-than-perfect API stability. In addition, the need to keep the API mostly stable for years at a time has somewhat slowed the pace of development and created a hesitation to expose “too much” API for fear of having to live with it “forever”.
We want to improve this, and we have a plan.
Everyone present for the discussion was excited about this plan as the best possible way forward, but it is not yet official. We will need to have discussions about this with distributors and, particularly, with the GNOME release team. Those discussions are likely to occur over the next couple of months, leading up to GUADEC.
We are going to increase the speed at which we do releases of new major versions of Gtk (ie: Gtk 4, Gtk 5, Gtk 6…). We want to target a new major release every two years. This period of time was chosen to line up well with the cadence of many popular Linux distributions.
The new release of Gtk is going to be fully parallel-installable with the old one. Gtk 4 and Gtk 3 will install alongside each other in exactly the same way as Gtk 2 and Gtk 3 — separate library name, separate pkg-config name, separate header directory. You will be able to have a system that has development headers and libraries installed for each of Gtk 2, 3, 4 and 5, if you want to do that.
Meanwhile, Gtk 4.0 will not be the final stable API of what we would call “Gtk 4”. Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it. These incompatible minor versions will not be fully parallel installable; they will use the same pkg-config name and the same header file directory. We will, of course, bump the soname with each new incompatible release — you will be able to run Gtk 4.0 apps alongside Gtk 4.2 and 4.4 apps, but you won’t be able to build them on the same system. This policy fits the model of how most distributions think about libraries and their “development packages”.
Each successive minor version will be growing toward a new stable API. Before each new “dot 0” release, the last minor release on the previous major version will be designated as this “API stable” release. For Gtk 4, for example, we will aim for this to be 4.6 (and so on for future major releases). Past this point there will not be disruptions; this “stable API” will be very stable. There will certainly not be the kind of breaks that we have seen between recent Gtk minor releases.
In this way, “Gtk 4.0” is not “Gtk 4”. “Gtk 4.0” is the first raw version of what will eventually grow into “Gtk 4”, sometime around Gtk 4.6 (18 months later).
The first “API stable” version under this new scheme is likely to be something like Gtk 3.26.
Applications authors will have two main options.
The first option is to target a specific version of the Gtk API, appearing once per two years, that stays stable forever. Application can continue to target this API until the end of time, and it will be available in distributions for as long as there are applications that depend on it. We expect that most third party applications will choose this path.
If two years is too long to wait for new feature, application authors can also choose to target the unstable releases. This is a serious undertaking, and requires a commitment to maintaining the application during a two year period, and keeping up with any changes in the toolkit. We expect that GNOME applications will do this.
Third party application authors can also follow the unstable releases of Gtk, but we encourage caution here. This will work for GNOME because if a single maintainer disappears, there will be others to step in and help keep the app up to date, at least until the next 2 year stable release. This approach may also work for other large projects that are similar to GNOME. With individual app authors, life can change a lot during two years, and they may not be able to make such a commitment. Distributions may decide that it is too risky to ship such applications (or update to new versions), if they use the unstable API.
In general, we feel that this approach is the best possible combination of two distinct and valid desires. Gtk users that have been asking for stability will get what they need, and the authors of Gtk will get additional freedom to improve the toolkit at a faster pace.
… now let’s see what we discuss this afternoon.
Pardon my cynicism, but this an awesome plan, because it will drive even more people to Qt and finally consolidate the Linux userspace.
Why not just use the traditional odd numbers for unstable releases and even numbers for stable releases?
How long will previous stable branches be maintained?
For example, once 3.26 is released, will there be a 3.28? If so, when does the 3.x branch come to an end?
3.20 —– 3.22 —– 3.24 —– 3.26 (3.x stable API declared) —– 3.28? —– …
Should use something like ‘Long Term Release’ to denote which versions developers should be targeting. The 4.0 vs 4 stuff is really confusing. So you can go from GTK 4.5 to GTK 4.6-lts. Something like that.
Also special consideration needs to be paid attention to things that directly impact users rather then application developers. Things like how theming works.. if having GTK3 and GTK4 side by side breaks theming then it’s going to be a big problem. Or maybe how menus work. Developers can pick and choose which specific toolkit they want to use, but it’s users that will be stuck with dealing with multiple GTK tool kits being used simultaneously by different apps. So they have pains that individual developers won’t experience.
Sounds like this effort will go along nicely with flatpak and runtime releases. With some consideration given to continuous engineering (CI) then developers should be able to track particular toolkit changes by targetting runtimes and be able to automate testing without dealing with upgrading OSes and such things. Should make it easier for developers to track the latest stable version of their toolkits with confidence.
Sounds like good stuff. Good luck.
The API will be stable only 6 months before the next major release?
Why GTK devs can’t guarantee stability after a major release like any other library?
This is way too complicated. You guys should read this: http://semver.org/
Consider using semantic versioning (http://semver.org/) and just incrementing the major version number more often. Then, designate e.g. every other major version line as “LTS” and support it for an extended period of time for third-party developers.
This is the approach Node.js uses, and it is way less confusing.
This sounds great. I think real care has to be taken in communication though, to make sure that people who seek stability really understand what releases they need to target.
It would be nice if GNOME would consider offering a long-term support branch at about the same time for distros too.
It sometimes feels like a GNOME app only gets bugfix updates for the first month or two after a stable release. After that, distros have to backport bug fixes themselves from git. That means that GNOME has effectively ended support before most of its userbase is even running the software yet (or had the chance to report bugs they find).
I remember a few years ago, a longer-supported GNOME release was discussed but I don’t think there was much buy-in for the proposal.
One of the biggest that I have with this plan is how you’re going to handle mixed Gtk+ versions loaded into a single app.
Gtk+-2.0 vs Gtk+-3.0 was bad enough, were if you wrote an application that used Gtk+-3.0 but one of your dependencies pulled in 2.0, it would crash (if you were lucky). If there are more versions hanging around – it appears that Gtk+ 2, 3, 4, 5, … might all be on a system at the same time – this seems like it would cause more issues?
Another thing I’m worried about is semi-infrastructure libraries – things like webkit-gtk – which will have to be updated in lockstep with gtk+ releases. They will need multiple parallel release streams, aligned to each gtk version, in order to remain useful – and keeping them all updated with security fixes seems like a pretty big deal (particularly given that the webkit folks stopped releasing security updates for their older ‘webkitgtk-3.0’ and ‘webkit2gtk-3.0’ apis in favour of ‘webkit2gtk-4.0’ while apps were still using the older ones).
I assume that after Gtk 4.6 (just to reuse your example) is released as Gtk 4, there will be additional releases containing bugfixes. How will you call them?
Whether it’s 4.6.1 or 4.7 or 4.8, developers who don’t closely follow the GNOME project will be left quite confused, on what release they should be developing on.
This sounds a lot like the sprint release cycle of TYPO3 which works once you get the gist of it but still doesn’t beat semver. Was semver considered as release scheme?
From Boudewijn Rempt (Krita Maintainer) on Google+:
“I had to ask my wife whether it really is June, and not April, and the 13th, not the 1st: https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ Um, now that I reconsider — we didn’t warp back to April 1st, did we?”
On IRC one darktable developer ton an other:
“should they really do that i’d vote to finally ditch gtk for good (or bad?)”
Come on, this is ridiculous!
KDE already tried it with “KDE 4.0 is not KDE 4”. This was a big flop.
How will this work with libraries? Will GtkSourceView have versions 4,5,6, etc for each major Gtk+ release?
It doesn’t matter if you tell people “elsewhere” that 4.0 isn’t stable and to wait for 4.6 instead. Most people won’t ever read or even try to understand that. Just number the releases following proper semver. There’s no reason to try to invent solutions for problems that have already been solved long ago, and a plus, have been solved in ways that are widely accepted. If instead of naming those releases with minor versions (4.0, 4.2, 4.4, 4.6), you name them with pre-release versions (-alpha, -beta, -rc1, -rc2 (or pre1, pre2, pre3. Or anything else, really)), them there’s absolutely no need to explain to anyone that these are not aimed at app developers yet, this information is already explicit in the version numbering. GNOME devs and distributors alike will know what to do, since they’re “insiders”. There’s no need to complicate things for third-parties.
Otherwise, for breaking changes, major version must change, as usual.
[TL;DR] Things must always be CLEAR and EXPLICIT for third-parties. Understanding project-specific rules can be imposed on insiders only.
Oh, man, this is just fodder for those who like complaining.
It’s also for the best.
Gtk+ 3 took a while to mature, till around 3.10 really, but it’s better than ever now.
So telling people that the latter point releases are where it’s at makes sense.
Developing against 3 < 3.10 was just irritating and a waste of time. Being able to target a specific runtime while catching up should work nicely.
And you guys get to play all you want without worrying.
I’m sorry, but you can’t be serious? Please think it through – all the way though – You will loose me as a developer – thats for sure. Don’ worry though, I am small. I only have about 20 projects.
P.S. What is the name of your Doctor? I would like to have a chat with him.
Will be GTK 4 the future sucessor of .NET Framework? Because .NET Framework practically haves the same development process that haves multiple versions and most of then are not used (only .NET Framework 2.0 and 3.5 is widely used that 4 and 4.5 versions on Windows due to Mono compatibility).
Unfortunately, this choice will mean a defragmentation of the users of GTK, and instead of accelerate the adoption of modern versions of GTK, stacks on older versions such like .NET Framework.
The title of this post sums up why this is going to be incredibly confusing.
Why in all that is holy are you going to release unstable apis with x.0 versions? Why don’t you call them betas like all proper developers do and call the stable versions x.0?
I think everyone is glad that the GTK+ team is looking into solutions for the problem of the restrictiveness of having a strict API/ABI and the need for a stable API that consumers can use.
However, this proposal only works if the sole consumers of GTK+ are applications or if everyone only uses Flatpak. The workflow you’ve outlined works reasonably well in that case. Distros ship all stable series and applications upgrade whenever they want or can.
In practice, libraries do use GTK+ (such as GStreamer, WebKit-GTK+, gtkmm, etc) and having multiple APIs and ABIs to support would explode the support matrix for such libraries and in the end for distros. From my experience as a distro packager and a GStreamer contributor, I’ll list a bunch of scenarios that demonstrate this.
* GTK+ 4.2 (unstable) is released. GStreamer adds support for it in the gstgtkglsink and gstgtksink plugins with #ifdefs and a configure option. However, distros can’t ship this support since it’s a compile-time option (no parallel installable plugins), so applications that use these plugins can only use GTK+ 3 (stable).
* GTK+ 4.6 (stable) is available. GTK+ 5.2 (unstable) is released. WebKit-GTK+ now has compile-time support for 3, 4, and 5. The maintainers swallow the bitter pill and split their library naming to allow parallel-installation of WebKit-GTK+ built with each version. But because the GStreamer gtksink plugins can only use one version of GTK+ at a time and many applications still haven’t been ported to GTK+ 4, distros can only ship the least-common-denominator support. But GNOME applications *require* GTK+ 5, and now distros are forced to ship old versions of GNOME Web and Evolution till every application that uses WebKit-GTK+ supports GTK+ 5. In the worst case this happens every 6 months with every API break.
* Same case as above, but GStreamer finds a way to parallel-install plugins. WebKit-GTK+ also supports parallel-installation of libraries. Applications have compile-time selection of all three. However, most applications stick with GTK+ 3 because they don’t have the manpower to keep up with API changes. Sadly, only the newest GTK+ has fixes required for proper Wayland integration. Will the GTK+ maintainers backport these fixes to older “stable” releases? When is a GTK+ stable major version abandoned? Having the wrong answers for these will alienate developers.
* Library X adds support for parallel-installation, but library Y doesn’t. Sadly, library X depends on library Y, so their parallel installation efforts go to waste and distros have to ship the lowest-common-denominator.
As you can see, this API/ABI scheme completely screws over libraries and by extension distros and even the GTK+ team in terms of maintenance. Not every library is going to agree to split their libraries, and most applications aren’t going to keep up with the latest GTK+ API/ABI breaks. I think this solution is completely untenable, and every distro maintainer I’ve talked to has been horrified by this proposal. :-)
It is rude to criticize without alternate proposals, so here’s one. Have GTK+ be built into two libraries: libgtk3 and libgtk3-unstable. The former *always* maintains API/ABI stability, and the latter breaks it with every release (with the appropriate soname bumps). When a portion of the API in libgtk3-unstable is deemed “stable”, it moves to libgtk3. I think this would solve the problem of API instability not being properly communicated to developers, and would allow new API to evolve as needed.
This also means that the GTK+ team has to live with API/ABI being available “forever” in the stable library, but this is the same requirement as every other library in the Linux ecosystem. It would be great to have a list of reasons why this doesn’t work for GTK+ so we can address those.
Instead of suffering garbage, would do fix jambs display elements. That window stretches across two screens with one line of text, or to a place of scrollbars, the more that. And it comes from the very inception GTK3. No, instead we suffer garbage and cut out features of Gnome, Gnome applications and breaking compatibility with other opensoftom. however, it is not treated, for CSS, consisting of some crutches.
Let bury better themselves and their gtk3.
Hey there,
I’ve read many comments on this proposed versioning scheme in a few places around the web, and I’m sorry to say that I couldn’t find people who liked this idea.
The main concern is that your use of version numbers goes against anything people ever seen, and as such, is not intuitive, a bit misleading and creates far too much confusion.
While the idea of providing truly stable GTK releases makes sense, the proposed way clearly needs to be rethought, and in that process, community feedback has to be considered.
It’s clear that you’re trying to achieve two main goals here:
* Be able to make breaking changes to GTK on every new GNOME release, which happens around every 6 months.
* Be able to offer truly stable releases of GTK, and a clear target for third-party developers.
As far as I can tell, this proposal doesn’t fulfill the second part of the second point.
So here, let me take a stab at it: let’s use the fact that the different GTK versions will be separated into different packages, and just use semantic versioning (“semver”) for each of the versions separately. The package name and version scheme can be GTK(ver) X.Y.Z for public releases, and GTK(ver) X.Y.Z-pre.W for development releases. (“pre” can be any other identifier; “dev”, “alpha”, “beta”, “rc”, etc.)
Following this scheme, GTK4’s first unstable development release will be GTK4 0.1.0-pre.1. When the next GNOME is released alongside GTK4, it will become GTK4 0.1.0. On a bugfix patch that may follow, it will be tagged GTK4 0.1.1. And finally, when the API is truly stable, it can be declared GTK4 1.0.0. Shortly after that, GTK5 0.1.0-pre.1 will be branched. At this point, on a bugfix release, GTK4 will be tagged as GTK4 1.0.1. If a non-breaking feature release happens to land for GTK4, it can simply be tagged GTK4 1.1.0. Regardless of GTK4 and its particular version, GTK5 0.1.0 will be released as part of the following GNOME release, and so on and so forth.
This particular proposal has quite a few advantages over the current one:
* Anybody can understand the stability status and what to expect from each specific version of GTK without ever having to look up information about it. This includes automated scripts. As a simple example, “GTK5 0.3-rc.2” is clearly the second release candidate for of the third bi-annual release of GTK. The fact that its version starts with 0 means that it’s not yet stable.
* Third party developers can have a clear target when they require forever-lasting stability. (they simply opt for the latest GTK which has a 1.* release)
* GTK developers have a great flexibility when it comes to clearly organizing development release cycle. For instance, it would allow the proper tagging of any kind of release, such as differentiating between development versions (-dev) and release candidates (-rc).
All in all, discussions need to be had.
I don’t dislike this idea, an LTS style GTK could work but please . . . PLEASE! . . . don’t make GNOME apps and Third-Party apps depend on different structures. This would just be a different type of headache.
If GNOME apps want to support the “non-LTS” versions then great but they should also support the “LTS” releases as well that way if a distro chooses the Stable and the majority of Third-Party apps choose the “LTS” then we won’t have such a mess to deal with.
Epiphany is a great example. Epiphany (aka GNOME Web, bad name btw) only gets new updates in distros when GNOME releases new versions so if 4.0 and 4.4 aren’t installable side by side then it means people who use a distro that selects 4.0 won’t be able to get any updates for apps that GNOME makes.
Please don’t do that.
I’m seriously confused, here. So if I’m writing a new app, you’re basically saying that I should ignore new Gtk+ releases until .6 or so, because they’re not actually considered suitable for use yet? That despite having made a .0 release, I should expect to be chasing API/ABI breaks for a year or so if I decide to use it?
Isn’t that the exact same problem KDE had with 4.0 and 5.0… fighting with the entirely natural assumption of developers that if you’ve made a .0 release, it’s expected that it’s ready for everyone to use?
Maybe I’m misunderstanding you… but this post comes across as a *major* deterrent to using Gtk+…
Sorry, I don’t buy it. The main problem is that this scheme is difficult to follow, because it is so different and unintuitive. Furthermore, you have no clear indication when something will be actually stable.
The Semantic Versioning (http://semver.org/) scheme is easier to digest and follows intuitive rules. There you have a clear indication when there are API / ABI breaks. If that means GTK starts getting into major version 456, so be it. No misrepresentation. No ambiguity.
Alternatively, if you want to have an continually unstable GTK, call it GTK 5.x and leave GTK 4.x as the super-boring and stable release. Once GTK 5 stabilizes, call it GTK 6 and leave it alone. New unstable development would then go in GTK 7.x.
The above odd/even versioning form is an adapted form of Semantic Versioning, where odd numbers are explicitly unstable, and even numbers are explicitly stable.
Hi Allison,
As an alternative, may I please suggest that the Gnome project adopt Semantic Versioning (http://semver.org/) for GTK releases?
I know a lot of people — our organisation included — who would not even start a port to a new version of a huge library like GTK+ without some understanding of what sort of ABI stability can be expected. Under you proposed scheme, we (and many other developers) wouldn’t even bother looking at GTK+ 4.x before GTK+ 5.0 had been released (and some sort of ABI stability had been established).
The Qt and KDE teams seem to manage to provide excellent library ABI stability over multi-year release cycles, even with the much greater challenge imposed by using C++. Surely it must be possible for GTK+ to do the same.
Or at least, please use semver and ldconfig versioning rules. I don’t mind installing GTK+ 246.0.0 if that’s what’s necessary.
Thank you for all your hard work on GTK+!
I think the problem is the name. You should name it gtk-experimentel and then release gtk 4.0 if it is ready and API stable.
its very ambitious, but, doe programs go to GTK4 GTK5 means that not all programs gona follow, so generally gnome stuf get the pace?
at the end you get some depency hell?
Just a little input from an occasional Gtk user… I’m a bit worried that you want to break compatibility so often (with each minor version).
You say an application could target a specific version, e.g. 4.2, and leave it at that. It would not break, but it will also not receive new features. One great thing about the “old” Gtk (2.x) was that it was incredibly backward compatible. I wrote a little tool many years ago in PyGtk, and it ran on (already then outdated) Gtk 2.12 I think, but it also ran on every version up to Gtk 2.28 without changes. It benefited automatically from new features, new themes, bugfixes, and so on. I tried it the other day, and it even runs on current Ubuntu. I never managed to produce anything for Gtk 3.x, because it moves so fast that my projects break before I can fix them (I don’t have much time to work on these side-projects, but I’d like them to be polished, and to run on multiple Gtk/OS versions – bleeding edge at home and whatever the old CentOS version at work has.)
I realize it is a bit more work for you developers, but the best thing for consumers of the libraries would be to only make backward compatible changes as much as possible. Only add to the library in minor versions, never remove (only deprecate). So a program that is compiled with Gtk 4.0 would be guaranteed to run with 4.2, 4.4, .. and so on.
You would be able to break at 5.0, and since you want major versions every two years this is a lot more frequent than it used to be, so you can remove cruft faster. However, breaking changes are always bad, and “break-the-world” updates always leave a large part of the user base behind (think Python 3, Gtk 3, …).
[ Here is a crazy idea (independent of the above): Always call the current major version the same thing, say Gtk3. If there is absolutely unavoidable breakage, instead of creating Gtk4 and waiting for apps to update, freeze the old version at Gtk3-2017 and call the new version Gtk3 :-). That way, behaving apps (that don’t use deprecated symbols) would continue to run, and non-behaving apps could either be compiled to a specific version, or get to run with a GTK_VERSION / LD_LIBRARY_PATH variable. I don’t know how feasible this would be, it’s just something that came to my mind. But it would be a solution to the problem that major versions often leave people behind. ]
Finally, I don’t understand why you say you’d be able to install apps targeting separate Gtk versions in parallel (4.2, 4.4, …), but you won’t be able to build them on the same machine. Do you mean these different runtimes would be using something like desktop app containers? Or each app would package their own dependencies?
I think a better way would be to install every installation in its own root, e.g. /usr/lib/gtk-4.2/… and symlink the current best versions to /usr/lib. You could even make distributions with known-good combinations of glib, gtk, …, for example /usr/lib/gnome-suite-2017-3/. This would also mean you’d be able to easily compile an app for 4.0 (by setting include and library paths appropriately) so that it would run with every 4.x without recompilation. Also, I’ve always found it rude for a program to clobber /usr/bin, /usr/lib, and so on.
Sorry for the lengthy write-up :-) keep up the good work! Versioning scheme aside, I’m curious to see what version 4.x will bring.
Hi Allison,
I’m so happy to read this. I’m delighted to see you talk about this issue and the way you’re addressing it is very good in my opinion.
GTK is a wonderful toolkit to work with. Our two concerns were that it might veer too much towards GNOME Shell (i.e. that GTK dialogs and widgets might not look “native” or properly “integrated” in other desktop environments) and that GTK3 was a moving target so it was difficult to ship GTK3 apps to different distributions (at the moment we need to target GTK 3.14 and GTK 3.18 internally, while supporting GTK 3.20 for Fedora and Arch users for instance).
We’ve seen you address the first point a few times.
And this post today is music to my ears. I hope it will boost your development. On our side it would definitely help a lot with stability and reliability.
Ok, first off, thanks for letting everybody know at an early stage.
I can imagine why marketing might want faster major revisions, and don’t like the 3.9x kind of versioning much myself.
But this proposal makes it impossible to see (from the version number alone) whether the final iteration of the Gtk API has been reached. Could be 4.6, could be 4.8. Next time around it might be 5.12.
So my suggestion would be to bump to x.100 and pronounce it “Gtk400”, for example. Avoids confusion with any previous “Gtk4 dot ” in cases where this differentiation matters.
I won’t judge this plan and idea, this is up to the developers only and maybe a good way for Gtk to gain more stability and users. But want I consider very bad is the numbering, “x.0” or 0-Release means stable, nothing else. GCC has done a similiar[1] thing and it totally bewildering. Instead of just critizing this idea I would suggest to think about other possible ideas to numbering or marking release. My first idea:
Gtk-stable-2.24
Gtk-dev-3.20 # current release
Gtk-dev-3.22
Gtk-dev-3.24
Gtk-stable-3.26
Gtk-dev-4.0
Gtk-dev-4.2
Gtk-dev-4.4
Gtk-stable-4.6
It would be linear, easy to understand and honest! Maybe other people have even better ideas.
[1]https://gcc.gnu.org/develop.html
— But want…
+++ But what…
Other suggestion, I even like this more, from Gtk4 ongoing:
Gtk4-0.1 # this is an officiall release, but just for six months
Gtk4-0.2 # this is an officiall release, but just for six months
Gtk4-0.3 # this is an officiall release, but just for six months
Gtk4-0.4 # this is an officiall release, but just for six months
Gtk4-1.0 # rock stable for ages
Gtk4-1.0.1 # small bugfixes
Gtk4-1.1.0 # handy new features, but still rock stable for ages
Gtk5-0.1 # this is an officiall release, but just for six months
The numbers below 1.0 still indicated an ongoing development, the numbers above indicated stability.
PS: You can even to crazy thing (would avoid it) and bump Gtk4 to Gtk4-2.0.0, it has to be still rockstable, but may add crazy things like “Wayland-Support” or a new supported operating-system.
Using 4.6 and avobe may will be confusing, When start to develop against?
While this is good because will push GTK development to new levels, may we need to skip 4.0 and go to 5.0, to use odd numbers for unstable API, when it reaches stable API switch to 6.0, here we can use 6.1 for testing bug fixed release and 6.2 for stable bug fix release; same could unstable odd versions, say 5.1 could be like Sid in Debian and 5.2 like testing for next stable release. Micro version for unstable could be for new versions, no bug fixed necessarily.
I’m all for speeding up development and breaking the ABI often. However, why not just bump the major release every six months instead and have every fourth release be an “LTS” release? It’s not like we’re running out of version numbers any time soon, and if you’re going to bump the soname anyway why not just let it follow the version number?
This seems like a well though out plan! Though, how will Glade support this release style? Will I be able to target a specific GTK+ version?
Why not just let the proposed gtk 4.0, 4.2, 4.4 be actually called gtk4.0alpha1, alpha2, beta1, etc. and the proposed gtk4.6 be the actual 4.0? To avoid confuse people and to keep with the conventional practices? You can break anything from alpha to beta and people will know that is expected.
It seems like a great step forward, but I’m worried about version proliferation. We’re gonna quickly wind up with five different versions of GTK+ installed on the system at once, each with a different theme. I would seriously consider using a three year cycle instead of two years, which would really help with this without making app authors wait too much longer for the new stuff.
Stabalize Gtk3 and do just this!
GNOME already suffers from the split between Gtk2 and Gtk3. A lot of applications doesn’t look similiar in behaviour and look. Now Gtk4 splits practically all GNOME-Applications away from every other application, which is using Gtk3 (assuming the stuff like Inscape, Gimp or the new Firefox-Sucessor will be ever ported to Gtk3).
We will never again have a full desktop environment which a great number of applications with the same toolkit. An this also doesn’t fix the issues around themes, basically the themes will be forced to support a stable Gtk3 and an unstable Gtk4. This is a nightmare. An as developer I will always want use the newest, but as maintaining developer I want the stable thing. This is painfull decision.
At first I thought ‘great’ this means stability, but in fact now your just splitting the desktop away from the applications, Gimp and so on will *never* use an unstable Toolkit.
Gtk2 never suffered from this, it was stable. Gtk1 applications? All ported soon. Qt never suffered from this, it is stable.
Do the one and only thing, the easy thing:
Just keep Gtk3 as stable and possible and slowly extend it via third-party libraries, if something proves to be good, merge it into the next Gtk3 release and maintain it.
Rationale : Great win with little effort.
Gtk4? You didn’t mentioned one reason what is wrong with Gtk3 itself and cannt achived without a massive API/ABI-Break.
Sorry. This howl split Gtk3/4 approach is flawed.
Brilliant.
GTK 1 – stable.
GTK 2 – stable.
GTK 3 – stable.
Yes, why continue there in a logical manner. Change a working system!
Go Gnomies, go!!!
You can do it.
Ehmm, do you even hear abou such things like Adapter, Facade or Decorator ?? Should be perfect tools for minor API changes… Also I would like to know do you plan more integration/relaying with/on Linux “initd” subsystem ? That would be terrible…
The proposed plan states that one won’t be able to co-install, e.g., the -devel versions of 4.4 and 4.6. This will cause troubles to distributions which build from source, such as Gentoo.