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" <[email protected]> To: [email protected] Cc: "Alen Siljak" <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
