Changing version numbers for novelWriter

[vkbo]

I'm considering changing how novelWriter uses version numbers. The format we have now, like 2.8.2, is not very intuitive. Since the app is now considered stable, this format is no longer as useful from a developer point of view either. Basically, we will just end up with 2-point-something forever because there is no reason to change the "2" any more.

The second reason is that the version number is now more visible to the user, like on the Welcome dialog. So it is better if the number is more relatable.

I see a few options that will all work fine:

1. Just drop the "2", so that after 2.8.0 comes 9.0, 10.0, etc. The second digit will then be used for fixes, so instead of 2.8.2 it would be 8.2. I could also drop the middle digit instead, so after 2.8 comes 3, then 4.
2. The other option is to do what many others do, and just use a YY.MM format, so the 2-digit year and the the month with or without a leading zero. Ubuntu does this, so does LibreOffice. If I made a release today, it would be 26.2. A fix to it would be 26.2.1.
3. A modified version of option 2 is YY.X instead where X is just incremental. So since there is typically two releases per year, this year would get a 26.1 and 26.2 release.

I like all of the above really, so if anyone on here have an opinion, it may make it easier for me to pick one. I do think the ones including a year are easier to relate to as a user, because it says something about how old the version you're using is.

Update

Here's an example of how an internal version number 26.1.1 could be displayed:

[peter88213]

So you're considering abandoning the major version number in the version numbering system. The welcome screen shown above looks good to me.
However, I could imagine that there might still be good reasons to increment the major version number in the future. For example, introducing a new file format. Or perhaps a rich text editor control (didn't you want to develop that with collett?). Or upgrading the GUI framework to a new look-and-feel.

[vkbo]

The point is that this versioning system is meaningless to most people, and is anyway designed for software developers who make tools and libraries for other developers. At this point, novelWriter is just a rolling release of new features. I don't want to break compatibility at all, so changing file format would still maintain support for all previous file formates, as I have done up until now. Updating the GUI is continuous anyway.

Currently, I've essentially used the version to indicate the alpha stage (0.x) the MVP stage (1.x) and the current stage (2.x). I don't see any reason to go to 3.0 that isn't perfectly fine with a YY.X versioning system either.

[peter88213]

In this case, there is nothing wrong with your intended system. Although, if you specify a patch level after the two-digit version number, as shown in the example splash screen, you are essentially retaining the conventional three-digit semantic versioning system and only shifting the digits to the left.

As far as the new version numbering for LibreOffice is concerned, it seems sensible to me as long as new releases are continuously appearing. Once they stop doing this because the software is truly complete (which was actually possible before the spread of the World Wide Web), the version number could seem unjustifiably outdated after a few years. With this system, you will end up with an aging version number. You can see the contrast with OpenOffice, where nothing has changed for ages (which makes the software attractive to me because there are no surprises to expect). Here, the transition from major version number 3 to 4 marks a backward-incompatible API change for the extensions. This aspect seems to be neglected in the LibreOffice version numbering system; here, API changes are hardly traceable for extension developers.

If you ever introduce an API, you can change the version numbering again. How about the systems for Ubuntu or for Intel processors?
Lutefisk could then follow smørbrød, or whatever it's called.

[peter88213]

Your question really got me thinking about the point of versioning schemes. For example, I have QuarkXPress 2015 installed, which nudges me every time I launch it because the version is obviously outdated. This is not the case with Photoshop 5.5, which I bought in 2000 for about a grand (or two?), in a box full of printed manuals, and which still runs superbly under Windows 11.

The developer of yWriter changed his versioning logic when he had already been at version 7 for a while. He suddenly revived versions 5 and 6 to continue them in parallel. Now they have the same functionality and code base as yWriter 7.x.x, but are compiled for older operating systems with different Dotnet versions.

Obviously, you can live with anything. Although—the longer I think about it, the more I like the idea of the aforementioned descriptive names, such as with Ubuntu, OSX, Eclipse, and Intel: Dapper Drake, Sequoia, Oxygen, Shasta ...

[therisingtithes]

Of the options suggested, I am particularly in favour of #2.

[vkbo]

26.3 would be the third feature release in 2026, and any bug fixes (no new features) would be 26.3.1, 26.3.2, etc. That's the normal CalVer model. You usually still need two numbers to indicate the date, but they just combine to a feature number instead of the major/minor distinction.

[vkbo]

This is the way pip, PyCharm, Ubuntu, and many others do calendar versioning.

[peter88213]

Already got it. You can see from the version number when features were last released or changed, if anyone is interested. Given novelWriter's issue list, there is also a case to be made for regular feature updates. There will probably be no gaps in the year.
With LibreOffice, however, they actually update several version branches at the same time.

Update

As indicated above, it seems to me that the purpose of calendar-based versioning lies in the developers' commitment to regular updates and in encouraging users to actually use these updates.

[vkbo]

LibreOffice has two fixed releases per year, and I expect they maintain patches for several of them at a time because they are included in Linux distros pinned to certain feature releases. I have this issue too as novelWriter is included in Fedora.

[vkbo]

Of the options suggested, I am particularly in favour of #2.

My only issue with #2 is that it works better for projects with a planned release cycle, which novelWriter doesn't have (at least at the moment). LibreOffice does this and has a 26.2 and 26.8 release in February and August this year. So I am probably settling on #3 instead.

The main issue with the month is that it becomes harder to do relevant pre-releases since you don't know the final month version in advance. It's much easier to hit a full year as a release target.

[Alok-S-Sharma]

It might actually make more sense to go with a YYYY.MM.<patch> style instead of YY.MM or purely incremental numbering.

I can’t recall every example off the top of my head, but I’ve definitely seen developers adopt full year-based versioning for better clarity and long-term readability.

Some well-known examples using date-based versioning include:

Ubuntu → YY.MM (e.g., 24.04)
Arch Linux → snapshot-based dates (e.g., 2024.03.01)
Twisted → YY.MM.patch (e.g., 23.10.0)
pip → YY.MM style releases
CalVer → explicitly defines formats like YYYY.MM or YYYY.MM.DD

Using YYYY.MM.<patch> has a few advantages:

Immediately communicates release age without ambiguity
Avoids confusion after decades (e.g., 26.2 vs 2026.02)
Scales cleanly long-term without running into interpretation issues
Still allows patch-level granularity (2026.04.1, 2026.04.2, etc.)

So for example, instead of 26.2.1, something like:

2026.04.1

…feels clearer and more future-proof, especially now that the version is user-facing.

If the goal is relatability + simplicity + longevity, full year-based versioning is arguably the most intuitive option.

[vkbo]

As already mentioned, MM needs planned release dates, which novelWriter does not have, so it is clunky and a moving target with the release model novelWriter has. I have settled on YY.MINOR.PATCH internally, which is expanded to YYYY on the GUI.

In any case, CalVer has many more variations than those you list, and pip does not use YY.MM, it uses YY.MINOR.PATCH like I'm proposing for novelWriter.

The version has always been user-facing in novelWriter, but most people who aren't developers don't care about version numbers. People will notice the year though, which is the main point of the change.