Hi John & Geert, Everybody has had a chance to express their opinion now. There doesn't seem to be a consensus on what the version number segments should be called in the community as a whole. There has been a lot of good information emerge that I would like to document in to the Development Process wiki section.
If you can both agree on a naming scheme, I think we should go with whatever you both think. How about Geert's latest suggestion: fundamental.major.bugfix ? Or should I just document them as FirstSegment.SecondSegment.ThirdSegment? Regards, Chris Good > -----Original Message----- > From: Geert Janssens [mailto:geert.gnuc...@kobaltwit.be] > Sent: Tuesday, 31 March 2015 1:32 AM > To: gnucash-devel@gnucash.org > Cc: David Raker; Chris Good > Subject: Re: Version Numbering > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
