Version Numbering

[Geert Janssens]

David,

Thank you for your input. It more or less summarizes what I believe is a 
pretty common versioning strategy in many free software projects. And 
since we are a free software project ourselves we"d need good reasons to 
follow a different route as doing so reduces the common knowledge 
advantage.

As to the choice of names for the version components I already stated 
I'm having major (no pun intended) issues with the "major.minor.x" 
scheme. Those may make sense for release managers, but not for users or 
developers.

Releases which bump the "minor" component in that scheme have often seen 
major new features in the eyes of developers who have spent countless 
hours of work on them or users who have been waiting for a long time for 
these. If anything, calling such a release a "minor" release is very bad 
marketing wise.

That's probably one reason you rarely see such a scheme on commercial 
projects. Many projects use years to version their products (Office 
2013, Ubuntu 14.04) or rapidly increasing first numbers (Fedora 21, 
Windows 7, Firefox 36, Chrome 41,...) and only add rarely add extra 
detail (like Windows 8.1 which could be considered as a bugfix release 
for Windows 8). OS X is an exception, although Apple is careful to use 
zippy names for each release.

Herbert already noted as well that the kernel project no longer really 
uses the "major" component. It's just arbitrarily updated.

So there are signs that the traditional meaning of the left-most 
component is slowly changing.

As are the times. Many projects are on higher frequency release 
schedules, and more and more the distinction between releases for 
bugfixes or for new features is being dropped or at least seriously 
watered down. For such projects the distinction between 
major/minor/bugfix is hard to make.

To be clear gnucash is still very traditional in that respect. Slow 
release cycles, stable releases (mostly) bugfix only. That may need some 
revision at some point to catch up with the rest of the world. But 
that's a totally different discussion.

I'm bringing all of this up to get us the think further than what has 
always been, not necessarily because it should change. It all depends on 
how much information one wants to code into the version number.

I'm fine with the 3-component versioning scheme. It works for our 
purposes and we can indeed decide with each release whether it has 
sufficient changes to warant a bump in the left-most component.

On the other hand I also like a year.month-based versioning scheme. 
Particularly for users this conveys a lot of information (which may bite 
as well if you are on a slow release cycle). I suspect our release model 
doesn't fit this versioning scheme though.

I'm also curious how the more rapidly changing first component release 
scheme would work for gnucash (which would validate "minor" for the 
second component again).

Both of these two releases go for a simplified versioning scheme at the 
expense of the amount of information that can be encoded in it. And 
personally I don't think gnucash is ready for either if you consider the 
compatibility component.

I do prefer the name shift from
major.minor.something
to
fundamental.major.bugfix
though. The first component change happens far too rarely to be called 
major. Or more importantly I think minor doesn't do honor to the work 
that goes into the big releases we do every 3-4 years.
I'm well aware this goes against the naming conventions usually adhered 
to by release managers.

Whew, lots of text again... Congrats if you made it this far.

Geert