> On Mar 22, 2015, at 9:51 AM, Chris Good <chris.g...@ozemail.com.au> wrote: > >> 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.)
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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
