> Date: Sat, 21 Mar 2015 21:17:50 +0900 > From: John Ralls <jra...@ceridwen.us> > To: Geert Janssens <geert.gnuc...@kobaltwit.be> > Cc: gnucash-devel@gnucash.org, Chris Good <chris.g...@ozemail.com.au> > Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods > to Advanced Portfolio Rpt > Message-ID: <673be364-1abd-403d-80f9-462013f46...@ceridwen.us> > Content-Type: text/plain; charset=us-ascii > > > On Mar 21, 2015, at 3:57 PM, Geert Janssens > <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 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
