Beyond 2.8 - some design thoughts
Geert Janssens
geert.gnucash at kobaltwit.be
Wed Dec 27 12:15:05 EST 2017
Op maandag 25 december 2017 01:49:41 CET schreef Alen Siljak:
> To me, as an outsider and an occassional tester, Semantic Versioning would
> make much more sense than any other custom versioning system. Simply
> because it is getting common across various software packages and
> libraries. It might work for the GUI application as well, when referring to
> the workflows instead of APIs. In that regard, I would always go for the
> "don't make me think" approach and stay away from numbering schemes that
> require a user manual to figure out.
> There's an answer on Stack Exchange that explains this into more detail:
> https://softwareengineering.stackexchange.com/questions/255190/how-does-sem
> antic-versioning-apply-to-programs-without-api
>
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