Version Numbering

[Chris Good]

> Date: Sat, 21 Mar 2015 21:17:50 +0900
> From: John Ralls <jralls at ceridwen.us>
> To: Geert Janssens <geert.gnucash at kobaltwit.be>
> Cc: gnucash-devel at gnucash.org, Chris Good <chris.good at ozemail.com.au>
> Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods
> 	to Advanced Portfolio Rpt
> Message-ID: <673BE364-1ABD-403D-80F9-462013F46B7D at ceridwen.us>
> Content-Type: text/plain; charset=us-ascii
> 
> > On Mar 21, 2015, at 3:57 PM, Geert Janssens
> <geert.gnucash at kobaltwit.be> wrote:
> >
> > Technically that is correct.
> >
> > However the unstable releases are not the focus of development. They are
> only pre-releases
> > intended for testing. They all eventually lead up to a "major/minor
release"
> in the next stable
> > series. And that release is the relevant one, not the unstable releases.
> >
> > So I think you can mention unstable releases, yet explain that
git-master
> will lead up to the
> > next "major/minor release" or stable release series.
> >
> > You'll note that I keep adding "major" as I really have issues with
calling
> these big updates
> > "minor". Perhaps we can have a brainstorm over this among developers
> and interested
> > commmunity members.
> 
> Yeah, I agree. Major releases are when the middle number changes and
> minor releases are when the 3rd number changes. Minor releases are by
> policy bug-fix only. (That should be in the wiki along with the numbering
> system). The first number changes only when we make huge architectural
> changes: The last one, from 1 to 2 involved changing most of the code from
> Scheme to C *and* upgrading the GUI from Gtk1 to Gtk2. I think completing
> the C++ rewrite of the engine including making it SQL query driven instead
of
> all in memory will merit a first-number change to 3, but I'm not going to
> promise that that will be done by 2017 so there will probably be a 2.8
series
> before we're ready for 3.0. If we subsequently change the GUI that might
> warrant another first-number change. But what's a good name for first-
> number releases? "Catastrophic" is probably correct, but isn't really an
image
> we want to project for user recruitment. "Enormous", "Earth-shaking", and
> so on sound silly. How about "!
>  Global" or "Fundamental" to indicate that the way the program works is
> different from before?
> 
> Regards,
> John Ralls
> 

Thanks for picking up my 'faux pas' re odd/even numbering (temporary brain
fade I hope).

I've done a little research on version numbering best practices.
http://en.wikipedia.org/wiki/Software_versioning is quite interesting.

Some of the commonly used version numbering schemes include:

Major.Minor.[buildno|bugfix|revision|patch]
Framework.Major.Minor

I totally agree with Geert that the 2nd level should be Major, not Minor.
John mentioned 'architectural changes' and I quite like
Architecture.Major.Minor although I prefer Framework.Major.Minor.

What does everybody think?

http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_read_my_
old_data_file.3F talks about major/minor and stable/unstable without really
defining them.

John, I agree defining our version numbering terminology should be done in
Development Process wiki.
(note to myself: add a link to there from the FAQ wiki.)

Regards,

Chris Good
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6091 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20150322/ab6dca40/attachment.p7s>