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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
