Version Numbering

[John Ralls]

> On Mar 22, 2015, at 9:51 AM, Chris Good <chris.good at ozemail.com.au> wrote:
> 
>> 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.)

I think "Framework" might be confusing. In general use it means a package of libraries, like a GUI framework of which Gtk is an example. Changing the GUI framework on which GnuCash is based would likely justify a first-number change, but there are other reasons too. Where did you find someone using that for "first-number" changes?

"Architecture" also has a bunch of special meanings in CS, but it does convey a more-major-than-major sense, but I'm not really any more enthusiastic about it than "Global" or "Fundamental".

As for the FAQ, it looks to me that the whole "Developing Gnucash: Source Code Overview" needs a rewrite, starting with the title: There's nothing resembling a Source Code Overview there.

Regards,
John Ralls