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 -semantic-versioning-apply-to-programs-without-api > > Option A: let's number development snapshots starting from x.90. That gives us > 10 development snapshots. If that's not enough we can either choose to start a > bit earlier, like x.80 or from x.98 jump to x.980 to give us 20 more. > Option B: as a variation all development snapshots do use a 3 number version: > x.99.z with 99 clearly indicating "right before the next major release" and z > incrementing with each snapshot. > I’m indifferent to the versioning system as long as it’s consistent, but the distro packagers aren’t. Some of them recite the “Semantic Versioning” [1] mantra even though it really applies only to libraries. Back when we released 2.6 we were unsure about whether the coming version would be 2.8 or 3.0. One of the criteria proposed was that we should call it 3.0 if we upgraded to Gtk+3. Well, we have, so maybe the coming release should be 3.0.0 instead of 2.8.0. That would certainly be consistent with the Gnome guidelines [2] that include a major change in the GUI as a reason for bumping the major version. Should some of the component libraries (especially libgnucash) have separate versioning that follows the semantic versioning rules? Regards, John Ralls [1] [1]https://semver.org/ <[2]https://semver.org/>[2] [3]https://developer.gnome.org/programming-guidelines/stable/versioning .html.en <[4]https://developer.gnome.org/programming-guidelines/stable/versionin g.html.en> References 1. https://semver.org/ 2. https://semver.org/ 3. https://developer.gnome.org/programming-guidelines/stable/versioning.html.en 4. https://developer.gnome.org/programming-guidelines/stable/versioning.html.en _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel