> -----Original Message----- > From: John Ralls [mailto:jra...@ceridwen.us]
> Sent: Sunday, 22 March 2015 2:59 PM > To: Chris Good > Cc: gnucash-devel@gnucash.org > Subject: Re: Version Numbering > > > > On Mar 22, 2015, at 9:51 AM, Chris Good < <mailto:chris.g...@ozemail.com.au> chris.g...@ozemail.com.au> > wrote: > > > >> Date: Sat, 21 Mar 2015 21:17:50 +0900 > >> From: John Ralls < <mailto:jra...@ceridwen.us> jra...@ceridwen.us> > >> To: Geert Janssens < <mailto:geert.gnuc...@kobaltwit.be> geert.gnuc...@kobaltwit.be> > >> Cc: <mailto:gnucash-devel@gnucash.org> gnucash-devel@gnucash.org, Chris Good > < <mailto:chris.g...@ozemail.com.au> chris.g...@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-462013f46...@ceridwen.us> 673be364-1abd-403d-80f9-462013f46...@ceridwen.us> > >> Content-Type: text/plain; charset=us-ascii > >> > >>> On Mar 21, 2015, at 3:57 PM, Geert Janssens > >> < <mailto:geert.gnuc...@kobaltwit.be> geert.gnuc...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
