[pezezin]

That is something that pisses me off immensely. If you see version 2024.2 you can immediately recognize it is a date, but 24.2 might be a date, might be a numerical version number, who knows.

Is it so costly to write the year in full?

[TillE]

Ubuntu is the first place I encountered this convention. You might think that Ubuntu 22.04 and 22.10 are closely related because the vast majority of software uses something that loosely resembles semver, but no, they're two different major releases. Very confusing.

[goku12]

Your comment made me look at the history of both Ubuntu and Semver. It looks like the earliest specification of Semver dates to 2011, while the first release of Ubuntu was in 2004. I remember being confused about how to version code until I encountered semver (Ubuntu scheme was the one I used for a short while). It's possible that Canonical was faced with a similar choice and decided to make one up. While schemes like semver did exist before it, they were not so ubiquitous and didn't have a well-defined meaning like semver does.

[kergonath]

Major.Minor.Patchlevel was used in the 1980s by the vast majority of Open Source or Free projects. This was a couple of decades old when Ubuntu was first released. The limit between major and minor is blurry, but we did not have to wait for a bunch of people to write a manifesto to use sensible versioning schemes.

[goku12]

> but we did not have to wait for a bunch of people to write a manifesto to use sensible versioning schemes.

That's such a cynical take. The 'manifesto' or the standard is important for two reasons:

1. The scheme wasn't obvious to inexperienced developers. You had to learn it from someone else. Semver standard made it possible for absolute beginners to search and follow the conventions correctly up front.

2. There are a lot of tools that use, support of enforce semver - especially language package managers like cargo, pip and npm. That ecosystem wouldn't exist without the unification provided by the standard.

[kergonath]

> That's such a cynical take. The 'manifesto' or the standard is important for two reasons:

I don’t object to the RFC at all. I don’t like it for several reasons, but it has a purpose and it is useful to other people. The points you mention are right. I would just add the caveat that I haven’t seen any real improvement in versioning schemes. Most projects, which were already close, follow it and a bunch of high-profile ones don’t at all, exactly like before.

What irks me a little is the idea that it’s normal for Ubuntu to do its thing because we did not have the concepts behind semver (“I remember being confused about how to version code until I encountered semver (Ubuntu scheme was the one I used for a short while). It's possible that Canonical was faced with a similar choice and decided to make one up”), but please let me know if I misunderstood.

Ubuntu’s scheme was clever and justified, but not because the alternative was mysterious. It was great to new versions being released at a specific point in time rather than when new features or breaking changes were ready. It was also quirky at the time, along with their animal codenames, and it helped them being seen as a new, modern distribution. But GCC, as an example of very high profile free software, has been more or less following semantic versioning principles since the 1980s. And as a teenager learning to code and immersed in the Open Source culture in the late 1990s, I can say that we knew perfectly well what was basically semver without the legalese.

[gsinclair]

This appears to be a misinterpretation. GP did not say or suggest that any standard or manifesto is pointless, only that it was possible to use good versioning systems prior to their creation.

[orra]

Fair. But, at least later on, that wasn't universal. There's x.odd for development releases, and x.even for proper releases. GNOME and Linux used to do this.

Also it feels like a lot of projects used to use 0.x numbers, even when they were widely used and stable!

[kergonath]

Indeed. And then there is the TeX versioning scheme.

[ako]

Was going to comment that sem versioning is much older than that, e.g., if I remember correctly version 6 and 7 (early 90s) used semver. Turns out that oracle also switched to year based versioning, thought it was still semver: https://docs.oracle.com/en/database/oracle/oracle-database/1...

Indeed confusing…

[goku12]

I started coding before semver was defined. There was no official name (so nothing to search with) and people had a vague idea about how to do it. That ambiguity meant that everyone did it differently and sometimes completely wrongly. The single name 'semver' and the document attached to it was a silent revolution. So many tools we take for granted (like cargo) are designed around it.

[probablynish]

This is the first time I realized that Ubuntu version numbers were linked to dates. Mind blown.

[Tijdreiziger]

Yes, and they always end in .04 or .10, because Ubuntu always releases in April and October.

[deciduously]

Except that one time it came in June - Dapper Drake was 6.06.

[joshxyz]

same lol

my understanding too is .04 memans lts and .10 means current like the nodejs release cycle

it's relieving to realize 04 and 10 are the months haha

[mkl]

Only every second .04 is an LTS release. 22.04, 20.04, etc. https://ubuntu.com/about/release-cycle

[littlestymaar]

Semver makes sense for libaries, but not much for user-facing applications.

[l72]

Sort of. For a desktop application, you are right, but for a server application like NextCloud or Jellyfin, semver or something similar can be really nice.

If I'm running ServerTool 2.2.0, and 2.2.1 is available, I immediately know that is a bugfix release and should be minimal to roll out (shouldn't have any breaking changes, data schema changes, etc).

If ServerTool 2.4.0 comes out, that means I probably need to look at the changelog to see if there are any special upgrade instructions or gotchas, however, it is probably pretty safe, and shouldn't have huge changes for users. I wouldn't expect any extensions or integrations to break either.

But if ServerTool 3.0.0 comes out, I definitely am going to test out in in a test instance and validate the upgrade. Any extensions I have probably also need to be upgraded to support the new version, so I may have to wait to deploy it. It probably also has UI/UX changes that affect my users, so there may be training that needs to happen.

Again, it really depends on the tool on what versioning system they should use.

[patmorgan23]

Semver makes sense for things that have dependents, that's always the case for a library, sometimes it's the case for applications as well.

[Dalewyn]

Windows 11 22H2.

Because writing Windows 11 2022 like any sane man would be far too unreasonable.

No, the H2 doesn't mean anything anymore. Once upon a time it stood for "Half", with H1 standing for "First Half" and H2 for "Second Half" of whatever year in two digits.

Of course, I still find this nonsense far more preferable to the bullshit that is the Chrome Version System where the entire number means jack shit.

[phpisthebest]

Then of course windows 11 22H2 is actually Windows Version 10.0.22621, and windows 10 22H2 is Windows Version 10.0.19045

[satvikpendem]

> Of course, I still find this nonsense far more preferable to the bullshit that is the Chrome Version System where the entire number means jack shit.

Why should it mean anything? It's just a succeeding number for every iteration, I find that vastly better than using dates or point based releases.

[Dalewyn]

Using a datecode shows immediately how old a given release is, which is useful information. I don't know how old Chrome 101 or Firefox 89 is; I know how old Windows 11 22H2 or LibreOffice 24.2 is.

Using a traditional Major.Minor.Revision.Build version number shows how much of the codebase is common between different versions. I can expect something made for one Major version to work in any other same Major version release, I can expect only a Revision or Build increment to include only very minor changes; likewise I can expect breaking changes between different Major versions. I don't know what Chrome 101 is other than it's after Chrome 100; I know NT6.0, 6.1, 6.2, and 6.3 are largely interchangable.

[amadeuspagel]

Chrome and Firefox are released so often that if the version number were a date it would have to include the day.

[cpeterso]

Including the day isn’t even enough because Mozilla actually releases two Firefox “Nightly” builds a day, one every 12 hours or so.

[satvikpendem]

For an end user product like Chrome or Firefox, the version number does not matter as much, it's really only useful for developers who might depend on specific versions.

[ozim]

This time and age I don’t believe anyone really depends on specific version of browser.

You could pull that maybe for a month. Longer than that and your customers will drag you through hot coals that you fix your stuff and move forward because you block security updates they need to install.

Unless of course you have it somewhere deep in company and it is IE8 app that no one can update.

But if you do anything public or SaaS platform you probably just fix stuff to support new versions or you are out of the game.

[fomine3]

MS start using H1/H2 for version since 20H2. An assumption is that "2009" is confusing or causes compatibility issue with older Windows release (Embedded 2009).

[orra]

That feels like an excuse. Windows compatibility mode is mature. The relevant APIs could easily return different values to buggy software.

[totetsu]

and then completely disregarding that version number that is shown easily to you, and making you remember which animal adjective matches to it when you want to download any file.

[tjoff]

The number of times I've had to google what the code-name actually refers to is mind-boggling.

There should at the very least be an included little cli-app that you can query and list versions.

[behringer]

I love the numbers. Hate the animal names. Guess thats the programmer in me.

[benj111]

what info does 7.6 give you?

If it's important enough to you that you keep track of libre office version numbers you'll probably remember it's a year.

If not, it's still no worse than the old system, so what's the issue.