In two recent blog posts by free software hacker Allison Lortie, the release principles for the next GTK versions 4, 5, etc, has been laid out.
According to the newly suggested scheme, “GTK 4.0” will be the opening version of the 4th series however it will be different than “GTK 4” which represents a finalized stable version.
The plan is to have the first few releases, e.g 4.0, 4.2, 4.4 – introducing new features and released every 6 months, building towards a finalized stable release.
– A good thing for those who are looking to utilize the latest technologies, sometimes at the cost of better stability, and are able to withstand rapid development pace.
However, the downside of these versions would be that they’ll also break each other compatibility.
Conversely, GTK 4.6 will be a stable version, that may also introduce new features, however unlike its predecessors, this version will be “very stable. There will certainly not be the kind of breaks that we have seen between recent Gtk minor releases.”
– A good thing for those who seek long term stability even at the cost of inventiveness.
Why 4.6?
Apparently, the seemingly arbitrary number stems from another goal GTK devs decided to set themselves in regards to subsequent versions.
The aim is to release a major version, e.g GTK 4, GTK 5, etc, once every two years. Therefore, increasing the overall development pace of GTK in general.
Nevertheless, the stable X.6 isn’t written in stone and there are still some things left to be sorted out.
For instance, for how long each X.6 version is going to be maintained and who will maintain a few of those in parallel?
Community Reaction
For the most part, the new release scheme suggestion is being met with favorable comments, especially by those who had an unpleasant experience with former GTK versions.
For those who are less familiar with the subject, both GTK in general and its 3rd version in particular have been criticized for lack of backwards compatibility, not once breaking such, between major and minor versions alike.
The rest of other reactions seem to focus on 1 main problematic area:
Semantic versioning (SemVer) – is a versioning convention which helps people (developers and users) keep track of current software changes and their kinds.
For example, GTK 3.18.2 is the 18th iteration of GTK 3, with 2 patches applied to it.
Now, the problem lies in the fact that 4.0 isn’t stable and so does 4.2 and 4.4, yet 4.6 is stable? How would a newcomer know that? What is the global logic behind it?
To that Lortie answers:
“we don’t believe that there is a huge amount of value in following every aspect of semantic versioning just for the sake of it. … if you are an actual application author who develops applications in Gtk, then it stands to reason that you probably know some basics about how Gtk works. Part of this knowledge will be understanding the versioning.”
Main Beneficiaries
According to Lortie, the target audience GTK is trying to satisfy can basically be divided into 2 different groups:
On the one hand, there’s GNOME which is a rather large group capable of (not to say requiring) a rapid development pace of GTK non-beta versions that would be in-line with their own versions.
And on the other hand, there’s third party application developers which due to the nature of their workforce quantity, are having stronger affinity towards stability and long term support.
These 2 groups should essentially represent the entire GTK crowd-base or at least their type should cater to the vast majority of it.
Although a few medium groups such as Cinnamon or Elementary OS are excluded of this focused targeting, it seem that they all fall well in between the two edges leaving them the possibility of choosing their favorable release strategy.
The Broader Picture
In essence, what GTK folks are suggesting is not much different than the de facto way upon which GTK 3 is going along.
Only difference being, this time GTK folks have took upon themselves to publicly announce that they’ll break compatibility, and Lortie seem aware of that:
“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.”
