Version Numbering

[Chris Good]

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.gnucash at kobaltwit.be]
> Sent: Tuesday, 31 March 2015 1:32 AM
> To: gnucash-devel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4821 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20150531/fed1ecd3/attachment.p7s>