> LibreOffice developers are moving to a year.month based versioning system.
The full year might be nicer, but personally I like this idea - it immediately let's you know how old of a version (or its initial feature set, in the case of LTS) you have installed.
For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.
> For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.
For Ubuntu people often use the codename (including in quite a few UIs, like [1]), something it presumably inherited from Debian, which does the same. I really dislike it, because I usually know which version number I want, but I rarely know which codename I want and always have to look it up on Wikipedia or the like.
The codenaming of the recent Debian releases has been particularly bad, with Debian 10 codenamed "Buster", Debian 11 codenamed "Bullseye", and Debian 12 codenamed "Bookworm".
Not only do they all start with the same letter, but the initial sound is nearly the same, too. It's way too easy to confuse them.
It's not if you don't keep track of releases. "Is Ubuntu codename 2 or 15 years old?" is basically unanswerable. even regular incrementing version numbers are easier: I don't keep track of Debian closely either, but I know "Debian 6" is pretty old, and Debian 12 or so is the latest version.
I predict a future post titled "LibreOffice 3000.01 will succeed LibreOffice 999.12". They'll sure feel silly, having to change the numbering system twice!
And often referred to only by that label, removing the benefit of the yearly naming scheme. Debian is the worst, which doesn’t even have the courtesy to alphabetize their code names.
> And often referred to only by that label, removing the benefit of the yearly naming scheme.
I guess it's nice to have code names, but you still need some sort of a reference to remember what is what and it's the same kind of extra step that you'd have to do with version 1.2.3. Years somehow feel more memorable, at least to me?
Though I've also run into issues with package management. For example, I want to setup a repository that has packages for Ubuntu 20.04 (focal), but I'm using say Linux Mint 20.3 (una) which is based on it locally, because that might be easier to use as a desktop OS (no snaps) or something like it.
Notice how the repository name is constructed dynamically? In that case, something like this might be returned instead locally:
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu una stable
Whereas what we might have wanted would be more along the lines of:
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu focal stable
In the example of Linux Mint, I guess them using different codenames sort of makes sense, because their release cadence is a bit different from that of Ubuntu, as are their version numbers: https://linuxmint.com/download_all.php
But at the same time, it's interesting just how much stuff the code names are used for and how things can break. I don't really have a solution, unless we want to have codenames be hierarchical, like bullseye_focal_una to indicate everything - the Debian, Ubuntu and Mint version in the example, and then have more intelligent tools pick the closest thing that exists.
The full year might be nicer, but personally I like this idea - it immediately let's you know how old of a version (or its initial feature set, in the case of LTS) you have installed.
For example, in the case of Ubuntu or Unity (the engine) you can tell what you're looking at, at a glance.