Version numbering
Posted by kimmov on January 26, 2009
Version numbers are always interesting topic. Although they really should not be. But people and users have used to things like “bigger version number always means better software”. Which is a bit uncomfortable for projects like WinMerge.
After all the version number is an identifier for the release. We could just give names for our releases (like some projects do). Problem with names is there is no clear clue about what is the latest release. And WinMerge project releases pretty often, several stable releases within a year. So version numbers have their merit too.
We have been actively releasing experimental releases which naturally have bigger version number than latest stable releases. We’ve named them experimental releases, we’ve written warnings in release notes that they really are not stable release. Still people use them because they have bigger version number. And even many download sites offer our experimental releases because the bigger version number. And it gets worse – I tried to add latest stable release for one download site but could not add a release with smaller version number than some experimental release!
We are changing WinMerge version numbering a bit. It should help with understanding our version numbers. Yes, current numbering sounded nice idea few years ago but it has became quite a pain. Back then we thought about “advanced” users who could figure out our system. But it has became painfully clear that many users don’t (bother) figuring it out but just download the version with biggest version number. No matter about categories or descriptions. Users want to use the latest and greatest version. Without thinking our nice numbering ideas.
It is hard to arrange releases so that the latest stable release will have the biggest version number. Only solution I could think of is using totally different numbering for unstable and stable releases. But then the relation and order of releases would not be clear anymore. I still want that we have linear release history so that certain unstable release series leads to stable release series. Unstable release series adds features and fixes for the next stable series. It is continuous development, not random hacking.
I personally feel it confusing that some projects use same numbering for stable and unstable releases. Sometimes I need to reads some release notes and changelogs to know if the release is stable or unstable as the version number and/or name does not tell that vital information. There are projects I don’t care being tester myself but use the stable releases. So WinMerge (and Frhed) will have clearly separated version numbers for stable and unstable releases.
In 2.13.x and later versions we only have three version numbers. First is two always. We aren’t ready to release 3.0 version of WinMerge. Actually I wonder when we could be. But updating version number to 3.0 would mean for users there is some real big changes. And I doubt we ever have releases with “big” changes. So we’ll stick with 2 for now on. Perhaps things like real cross-platform support or real 3-way merge could make the 3.0 release…
Second number is even (2.12) for stable releases and odd (2.13) for beta- and experimental releases. Third number is just counter. It starts from 1 and we’ll increase it by one for each experimental release. For beta release we may bump it a bit more. For example first 2.13 experimental release was 2.13.1. Next will be 2.13.2 and so on. First 2.13 beta release will probably be 2.13.10 or 2.13.20, depending how many experimental releases we release before it.
This also means making the difference of beta- and experimental-releases smaller. They both are unstable releases from user’s point of view. And we may in future just combine these two categories into one “unstable” category. Simplicity is good.
