Beyond 2.8 - some design thoughts
Alen Siljak
alen.siljak at gmx.com
Fri Dec 29 04:11:08 EST 2017
I'd like to add that, to me, the difference between stable and unstable
version is obvious enough if I see v2.8.0-alpha1, 2.8.0-alpha2,
2.8.0-beta1, 2.8.0-rc1, and then 2.8.0. I see no need for separate
version numbers.
However, I don't feel strongly about the version numbers as long as
they make sense. The above is just something I'd instinctively
recognise if I did not know absolutely anything else about the project
at hand.
The same goes for major/minor version. For example, in the projects I
contribute to (at work or privately), I tend to continuously update any
dependencies that have minor version updates, assuming they contain
only minor improvements. Bug fixes (the third number) are almost
mandatory updates as they often correct issues that we identify
ourselves.
Major version change requires more time and effort in checking what has
changed and hence doesn't get updated readily. That usually involves a
migration path and coordinated effort.
All this information is fairly obvious from just those three numbers.
Happy New Year!
Sent: Wednesday, December 27, 2017 at 6:15 PM
From: "Geert Janssens" <geert.gnucash at kobaltwit.be>
To: gnucash-devel at gnucash.org
Cc: "Alen Siljak" <alen.siljak at gmx.com>
Subject: Re: Beyond 2.8 - some design thoughts
I do agree up to some point. I consider the scheme I propose to be
mostly a
simplified form of the semantic versioning. We will use one level less,
because we don't distinguish between bugfixes and compatible features.
I can
understand why this is suggested for libraries. The reality is we
haven't been
doing this for years. Also with every major release (2.6.0, 2.8.0,...)
we have
been introducing backwards incompatible changes. According to the
semantic
versioning this means we should have updated the first number rather
than the
second one. So applying the rules of semantic versioning on gnucash in
the
past would have been misleading.
Geert
More information about the gnucash-devel
mailing list