5 ms·
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
by chungy 6y ago
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.
- bch 6y agoNetBSD 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.
- layer8 6y agoThe problem is that "4.0" sorts before "4.0-alpha.1". Not saying that 3.99 is better, but something's gotta give.
- deathanatos 6y agoIf you're lexicographically sorting, maybe? But if you're doing that, 3.10 and 3.2 won't sort correctly, either.
- Lammy 6y agoYou can write a locale for LC_COLLATE to make pretty much anything sort any way you'd like :) http://www.unicode.org/reports/tr10/ http://www.unicode.org/reports/tr10/
- itp 6y agoNah, 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/VersionComparison 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.
- jdub 6y agoHa ha. waves
- evancordell 6y agoI 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 https://semver.org/#spec-item-11
- chungy 6y agoSemantic 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".
- Quekid5 6y agoPfft... The versioning scheme is the least of GTKs problems.
- jdub 6y agoGTK 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. :-)
- saagarjha 6y agoSeems a bit confident, no?
- wott 6y agoIndeed: 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.
- jdub 6y agoThat'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.
- jdub 6y agoI'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. :-)