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