My input probably isn't very merited, since though I joined this list with the intention of contributing, I haven't actually found the time. Nonetheless, I do some development and systems administration for clients, and when discussing version numbers what I most commonly encounter (and use on software I write) is as follows:
The first level is generally refered to as the major version, the second as the minor version. The third level is more variable, but is usually release, or sometimes patch or point. If someone has not read your documentation or doesn't know otherwise, that is how they will most likely refer to versions, and thus probably the most rational to use. As far as expectation of what the number implies, I would generally assume that a change in the first number indicates a change in major components that is likely to affect compatibility. A change in the second number indicates a lesser milestone, perhaps with new features, but may or may not also break some compatibility. Changes in the third number are often bug fixes or other changes that should never break compatibility if at all possible. Obviously the onus is on an administrator to do due diligence to ascertain that this sort of assumption is true before updating things. Preferably, things which affect interoperability get added or deprecated at changes in the minor number or above, but only removed completely at changes in the major version. While this might mean that in a client/server environment, for instance, that a client versioned 2.4.x cannot use new backend features from 2.6.x, it hopefully should not mean that client 2.4.x cannot function with backend 2.6.x because something it requires is gone. Rolling back the data storage layer to an old minor version might well still be lossy, since new features are gone. I wouldn't take bets on whether client 2.6.x can use backend 2.4.x either, since that probably means it needs to constrain itself based on capabilities of the current server. With regard to the changes you have been discussing, I would normally assume that a rewrite in a new language, eg the move to c++, would be accompanied by a major version change, but since I think that is going one component at a time, perhaps not. I would still try to keep changes that introduce new dependencies or otherwise change build requirements at minor version numbers. The multiuser functionality would merit at least a minor version bump, if it somehow came without a major change in architecture. I would think the change from loading the whole data store into memory to a system that reads and writes changes incrementally would be significant enough for a major version, though, since that is a pretty big change in the core architecture of the application. Incompatibilities in scripting/extension languages would also need at least a minor version change, and removal of a scripting/extension language should only happen at a major version change. Any way you do it, if you mean for the first level number only to ever change when something earth shattering happens, like a framework change or a complete rewrite of the system, it will probably never happen, since yours is a decently large, mature project. That is, if I'm not mistaken, the realization Linus came to when he finally bumped the Linux kernel to 3, more or less at random. I will now go back to lurking in a more appropriately silent way until I have time to actually be useful. On Mar 28, 2015 7:02 PM, "Chris Good" <chris.g...@ozemail.com.au> wrote: > Hi All, > > I've asked for people to give their opinions on a GnuCash version numbering > system as, from my few small documentation contributions, I think this > should be defined somewhere. > > I'll summarise what I've observed so far now that's it's been a week. > > There has been some good input about what the 3 segments of the GnuCash > version number should be used for, although there is no general consensus > and some people are OK to leave the decision till later, or maybe decide if > the first 1 or 2 segments should change on a case by case basis. > > We don't seem to be getting anywhere picking names for the 3 segments of > the > version number, particularly the first segment. > We've had the following suggestions (in no particular order): > > First Level: > Major > Architecture > Global > Fundamental > Framework > Basic > Base (I'm throwing this into the ring here) > Second Level: > Major > Minor > Third Level: > Minor > Micro > Bugfix > Point > Revision > Patch > > Have I missed any? > > I think it is generally agreed, (from the small number of opinions > expressed so far), that level 2 should be Major and level 3 should be > Minor. > Can everyone that has an opinion please let us know, particularly regarding > the level 1 name? > > Regards, > Chris Good > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
