Hacker News Reader

Comment by chungy | Hacker News Reader

It's a serious blast to the past, and not necessarily a good one, to see versioning treated like this, where they'll pick 3.9? as a form of alpha/beta/RC phases for 4.0.

I think semver (more-or-less a formalization of what was already becoming popular before semver got published) makes more sense. Go ahead and use 4.0-alpha.1, 4.0-beta.1, 4.0-rc.1 as needed. The strings still sort fine.

View on HN

GTK is a 22 year old project.

Both GTK and GNOME have used .99-style release candidate micro numbers, and odd/even minor numbers to represent devel/stable (as Linux once did) for a VERY long time. ~18 years ago, GTK/GNOME decided that major number bumps meant breaking changes.

.99 means "we're absolutely serious about this release candidate" because you know you're going to eat it if you ship a three-digit minor. How embarrassment.

Kids, a bit of community tradition won't hurt you. :-)

Seems a bit confident, no?

Indeed: as it is said in the post, they had to give up on a feature because they could not implement it in time for their .99 version and they locked themselves in that system.

That's less about the version number, more about the time-based release train. If you're not ready to go, you can't get on.

GTK/GNOME started doing time-based releases every six months 18 years ago. Hasn't missed a beat.

I'd trust Matthias to know when GTK is ready, and it's a signal to the community that it's definitely time for testing and porting. But he can still make micro bumps. :-)

The problem is that "4.0" sorts before "4.0-alpha.1". Not saying that 3.99 is better, but something's gotta give.

If you're lexicographically sorting, maybe? But if you're doing that, 3.10 and 3.2 won't sort correctly, either.

You can write a locale for LC_COLLATE to make pretty much anything sort any way you'd like :) http://www.unicode.org/reports/tr10/

Nah, this was never really about lexicographic sorting. Pre-semver, there was general consensus between systems like dpkg and RPM about how version numbers worked. This is a bit of a simplification, but it roughly works out like this:

* Split version number into version numbers separated by non-alphanumeric components (e.g., 3.10.2 becomes (3,10,2) and 3.2 becomes (3,2)).

* Compare two versions item by item numerically (in this case, 3==3 but 10 > 2 so 3.10.2 is newer than 3.2).

This is a massive oversimplification, and if you're curious you can read more at https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComp... for the gory details.

Source: long ago I worked at a company named Ximian that shipped a software update product that worked on systems using both RPM and dpkg, and I had to deeply understand this problem space.

Ha ha. waves

I suspect they're referring to the semver sorting rules as written in the spec:

> When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:

> Example: 1.0.0-alpha < 1.0.0.

see: https://semver.org/#spec-item-11

Semantic sorting has existed for a long time. GNU coreutils have been able to do a "version sort" for years (eg, "ls -v" or "sort -V"), using the Debian rules which also happen to be a superset of semver. "4.0~alpha.1" sorts before "4.0".

NetBSD does similar (major.99.iteration), and before its alpha or beta, this is where things get hashed out. It’s a reserved magic number (one hopes there aren’t 99 minor releases that would start a conflict over x.99.y) so that sucks (being “magic”), but it seems to work out in practice.

Pfft... The versioning scheme is the least of GTKs problems.

Reply on news.ycombinator.com