Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

As someone who follows Semantic Versioning like the bible when my API changes I find it incredibly interesting that there is an open source community willing to go about it in such a backwards way. Why wouldn't it be GTK 4.0-ALPHA, GTK 4.0-BETA, GTK 4.0-RTM in which case RTM is the final release that's stable? Why would you release an API as an X.0 that is unstable?

Maybe I'm not as "with it" as I thought with open source communities but I've just never seen this (and I'm sure there are edge cases but GTK is big; seems like something important you'd want to be more stable than not that adheres strictly to semver).

View on HN

I think I understand it. The X.0 is basically the start of a new technology branch -- it's radically different than what came before which is why it's a new major release. And of course any new radically different piece of software will not be stable, so X.0 represents the most unstable version of this new technology and theoretically X.Y where Y is the latest point release is then likely the most bug free and stable.

Perhaps this makes more sense in a world where software never needs to be finished.

This is, strangely? The release cycle that KDE Plasma uses. 5.7 just came out, and is the most stable and feature complete 5.x. You should always upgrade your Plasma 5.x, because newer versions are not revolutionary like 5.0 was, they are incrementally better. 4.12 vs 5.0 at release were not even comparable - 5.0 was completely broken.

The difference is, that is KDE Plasma. KDE Frameworks, the libraries, are abut to release version 5.24, where they have been getting monthly releases but upon Frameworks 5.0 release they were stable and better than the already existent KDE Libs 4.12 to start out. They are also always backwards compatible, but have incrementally added new features and frameworks between releases. You know, like a real toolkit.

And the same applies to Qt upstream, except it does better than Plasma. Qt 5.0 was flat out better than 4.8 right out of the gate, and only gets better. It is also mostly backwards compatible, insofar as it does depreciate and remove features but only over the course of multiple releases. Qt Script only just got removed in 5.7 after being depreciated in 5.0? I believe.

The real takeaway should just be that GTK is not a real product, and nobody who wants to make real usable maintainable software should touch it with a ten foot pole. Qt has been great for ~5+ years, and is only getting better (and its getting a lot better every year) so I have no idea why anyone is still even looking at GTK. If you don't like C++, you can do Qt with pure Python or Javascript as well.

> Perhaps this makes more sense in a world where software never needs to be finished.

(warning, rant follows)

I think this hits the core of the matter. This kind of release cycle - and API design - reflects a way of thinking where the complete ecosystem is expected to be constantly change. Why bother to keep a stable API if "everyone" has automated updates and all programs that could potentially use your API have a full-time development team behind them, ready to instantly react to every announcement you do.

Backwards compatibility? Not-for-profit one-man projects? Long-lived software? Naaah, were in the era of the cloud now.

Updates are important and at least security-critical software should obviously be maintained. However I think this shift currently goes a lot further than necessary, making constant flux the new normal and articles like this show why this is a bad idea.

Cloudcuckoolanders seems to be a fitting description of many of the people involved with Gnome/Freedesktop these days...

The right way to do version numbers is that the client/caller says "I am complying with version N of the API spec", and the server/callee says "I understand spec versions X through Y at this endpoint". If N < X or N > Y, the transaction is rejected. This applies on a per-endpoint or even a per-function basis, not to the whole system.

If the server gets more functionality, Y can increase. Increasing X breaks some existing programs, but callers which still speak an old version can drop back to that.

The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is progress in the sense that it has a specification that means you can assign meaning to the versions, but hey, so does the proposed versioning scheme for GTK. It is just not semver.

I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:

Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).

Android uses an interesting brand-version and actually-useful-version scheme (API level) https://en.wikipedia.org/wiki/Android_version_history This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.

And then of course there are the funky oddballs: https://en.wikipedia.org/wiki/TeX This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).

There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.

> The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others.[...]it can be confusing if you think that semver is the only game in town

I certainly don't think semver is the only game in town but the vast majority of versioning techniques out there are very, very similar to semver where major updates are the only ones that can affect the API. I wouldn't expect semver to suit everyone (honestly I prefer a slightly different version that was more common in the .Net universe) but at the same time most versioning techniques behave similarly.

The Gtk way is fine if it works for them but it certainly isn't common. Versioning is one of the very few things that I would be willing to give up what I think is ideal to settle for something most commonly used (why I use semver when working in JavaScript). I'm not sure what the most common versioning scheme there is but at least anecdotally it seems fairly similar to semver or at least a subset of semver.

Or if they really need so many minor version numbers before the first stable release, they could do the odd-even thing, where odd major versions are devel and even major versions are stable. So skip to 5.x for the next development cycle, then bump to 6.0 when the API becomes stable. Then 7.x for devel, 8.0 for stable, etc.

That's pretty much what they've been doing so far, except with minor versions (e.g. 3.19 was the development version of 3.20).

This decision isn't finished. There will be extensive discussion about it during the followup hackfest in August.

But as for shipping -alpha, -beta, etc, it would also look very weird if GNOME shipped -alpha as a dependency.

Reply on news.ycombinator.com