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