Version Numbering

[Chris Good]

> -----Original Message-----

> From: John Ralls [mailto:jralls at ceridwen.us]

> Sent: Sunday, 22 March 2015 2:59 PM

> To: Chris Good

> Cc: gnucash-devel at gnucash.org

> Subject: Re: Version Numbering

> 

> 

> > On Mar 22, 2015, at 9:51 AM, Chris Good <
<mailto:chris.good at ozemail.com.au> chris.good at ozemail.com.au>

> wrote:

> >

> >> Date: Sat, 21 Mar 2015 21:17:50 +0900

> >> From: John Ralls < <mailto:jralls at ceridwen.us> jralls at ceridwen.us>

> >> To: Geert Janssens < <mailto:geert.gnucash at kobaltwit.be>
geert.gnucash at kobaltwit.be>

> >> Cc:  <mailto:gnucash-devel at gnucash.org> gnucash-devel at gnucash.org,
Chris Good

> < <mailto:chris.good at ozemail.com.au> chris.good at ozemail.com.au>

> >> Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods

> >>       to Advanced Portfolio Rpt

> >> Message-ID: < <mailto:673BE364-1ABD-403D-80F9-462013F46B7D at ceridwen.us>
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

> >> < <mailto:geert.gnucash at kobaltwit.be> 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>
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_re>
http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_r

 <http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_re> >
e

> > ad_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

 

Hi John,

 

I'm not sure where I got the idea for "framework" as "first-number". I
cannot find anything about it now. I probably just saw it on the wiki
<http://en.wikipedia.org/wiki/Software_versioning> Software_versioning page,
not specifically as part of a version numbering system, and liked it more
than architecture as architecture has hardware/OS connotations to me. I
shouldn't have put it under 'commonly used version numbering schemes'.

Architecture is also just something I thought would be acceptable for the
"first-number".

 

Framework does have package libraries connotations that may rule it out. I'd
be OK with framework, but your "Global" or "Fundamental" suggestions
certainly have fewer connotations so may be better.

 

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/4f9a8850/attachment.p7s>