More Planning Details For GTK4 & Beyond

[phoronix]

Phoronix: More Planning Details For GTK4 & Beyond

Coming out yesterday from the start of GNOME's latest GTK+ hackfest were details on GTK+ 4.0 and future releases whereby they would change how they enforce API stability and how frequently they do major stable releases of the toolkit...

http://www.phoronix.com/scan.php?page=news_item&px=GTK4-More-Details

[oleid]

Reading the thoughts about semantic versioning on the blog, the approach seems pretty reasonable. In any case, the new approach will improve the current situation.

[starshipeleven]

He comes and clarifies yesterday's post at least:

something that they have been asking for for a long time: a version of Gtk that has the features of Gtk 3, but the stability of Gtk 2. Under the proposed scheme, that version of Gtk 3 will be here in about a year. Gtk version (let’s say) 3.26 will be permanently stable, with all of the nice new features that have been added to Gtk 3 over the last 5+ years.

Good, so GTK 3 will become stable in a year, this is the only thing non-GNOME-but-GTK-based DEs care about. The rest is irrelevant.
Once it is stable it can remain stable for decades like GTK2 and unlike GTK2 it supports wayland so unless there are other major changes there won't be a good reason to closely track GTK's future development.

In short: we get more freedom to make major changes during minor releases during the “early days” of a new major version. We advertise this fact clearly. The speed of development will increase. Once we are done breaking things, we very clearly advertise that “Gtk 4 is stable” (around Gtk 4.6). At this point, people know that they can port from Gtk 3 to Gtk 4 and get two years worth of new features with none of the fear about instability.

So the .6 thing is more like a rule of thumb. More like a "we play all over for various releases, then at random we decide to make a LTS with whatever the fuck number it has, probably .6 or higher" (knowing them, higher than .6). What matters is the announcement "GTK xyz is stable now".

Ok, this can make sense.

And the same is repeated here

The new system makes it clear that, during the first 18 months of releases, the Gtk 4 series is absolutely going to be unstable, and you should not target it. On the other hand, when it does become stable, this fact will be very clearly communicated, and you can trust that there will not be any changes of the sort that have hurt some of the users of Gtk 3.

The explanations about why they came up with the current versioning is madness. No seriously it's nonsense.

One possibility that we discussed was to release Gtk 4.0 (gtk-4.0.pc) and tell people that this is the new stable API that they should use. This would not work well with our current situation. There are currently many hundreds of applications using Gtk 3 which would have to go through a mostly-pointless exercise of changing to “gtk-4.pc”, with almost no changes, except a different version. We wanted these people to just be able to continue using Gtk 3, which would suddenly become much more stable than it has been. This is pretty much exactly what everyone has been asking for, in fact.

Then start from gtk 3.xx as it is now marking the first stable release. Isn't it what you plan to do with the 4.something and later releases? break things and then after a while declare that "after version .6 is stable"?

Let’s say we ignored that and did Gtk 4.0 as the new stable release, anyway. We would want to start working on “Gtk 5” immediately. Where would that work go? What would the version numbers look like? Gtk 4.90-rc, progressing toward Gtk 5.0? We would never have any minor numbers except “.0” followed by alpha/RC numbers in the 90s. This also means that most releases in the “4” series (4.90, etc) would have “gtk-5.pc”. This approach was just too weird. At the end of the 4 cycle, it is reasonable to imagine that instead of 4.7, we might call it 4.99, and have a pkg-config file named “gtk-5.pc”, but we will never have a non-development version (non-odd minor number) with this inconsistency.

WAT. Just WAT. "reasonable to imagine" my ass, I'm not able to follow any kind of logic here, it's all arbitrary stuff coming from nowhere.

In any case, if you look at our proposed system, you see that we still mostly follow semver, with only one exception: we allow for API breaks between early even-numbered minor versions. According to many of our critics, we were already kinda doing that anyway.

???????
They break things regularly.

[Mystro256]

Ah... So basically when the next *.0 version comes out, the old version is deemed stable... I guess that's ok, albeit a little unintuitive.

[Delgarde]

Ah... So basically when the next *.0 version comes out, the old version is deemed stable... I guess that's ok, albeit a little unintuitive.

That seems to be the biggest complaint, now that the newer post has clarified things a bit... it's a versioning scheme that works for the Gtk developers, but doesn't make much sense for developers using Gtk. I'm also not clear on where actual unstable development work happens - the implication seems to be that *.0 releases will be stable code that apps can use, just with no commitment to stable API/ABI. Perhaps there are no such development releases anymore, and developers wanting to check out an upcoming release need to build from Git? Or is that the point of this scheme, that third-party developers can just wait for the formal release of a 4.2 or 4.4, and then port to it?

I guess confusion continues to reign. I suspect much of this discussion is because the Gtk developers are communicating stuff they're discussing in their Hackfest... even though some of those ideas may not be ready for public attention yet...

[rastersoft]

Ah... So basically when the next *.0 version comes out, the old version is deemed stable... I guess that's ok, albeit a little unintuitive.

But also the old version will still receive bugfixes. This is very important.

[justmy2cents]

Reading the thoughts about semantic versioning on the blog, the approach seems pretty reasonable.

i would be happy with just stable version. this approach with regular stable releases and development geared into fast pace is just icing on the cake

In any case, the new approach will improve the current situation.

understatement of the century? last stable api is now 15 years old since there were no real drastic changes ever since 2 was started

[oleid]

i would be happy with just stable version. this approach with regular stable releases and development geared into fast pace is just icing on the cak

According to the developers, there was no real stable version of GTK+3 -- dunno about that, my last GTK+ code was for GTK+2.x

That seems to be the biggest complaint, now that the newer post has clarified things a bit... it's a versioning scheme that works for the Gtk developers, but doesn't make much sense for developers using Gtk.

Softwaredevelopers read the documentation of the libraries they use. If they do, they discover what the current stable version of GTK+ is. Problem solved.

Or is that the point of this scheme, that third-party developers can just wait for the formal release of a 4.2 or 4.4, and then port to it?

Exactly that is the intention. And for those, which need a feature, which got released with 4.0, their software will automagically use 4.6 once it got released. If only ABI broke, then a simple recompilation is enough.

Proprietary software will target LTS distributions, which will include GTK+4.6++

What they are trying to accomplish is to satisfy both camps at the same time: those who want the latest features and those who want more stable releases. The former will quickly adopt X.0, the later will stay with (X-1).6 as long as they like.

[justmy2cents]

According to the developers, there was no real stable version of GTK+3 -- dunno about that, my last GTK+ code was for GTK+2.x

i was referring to this new approach where they will put out stable every 2 years. FINALLY! no matter how much i wished for this, i probably like the development model even more because it is geared into fast paced evolution. usually projects take the other way around. putting out stable and then updating it for a long time. here they can use 2 years to create best possible outcome and then just stabilize it with asap moving on the next evolution. at least to me it sounds as most efficient plan possible. i can only say that if this really comes true, i'm gonna be one really excited camper

last stable is 2 something which is not old. main problem being that since 2 had API/ABI non-break restriction it evolved barely anything in whole lifetime, so you can safely say last stable api is 15 years old.

[boxie]

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.