Version Numbering

[David Raker]

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.good at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>