Op vrijdag 29 december 2017 10:11:08 CET schreef Alen Siljak: > 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.
That's a good point. I should check though whether our build system can handle this. If it does or if we can make it so, using explicit alpha/beta/rc strings would be very clear. It would be also require some getting used to as until now we never made an explicit distinction between alpha/beta/rc (though we imply it sometimes in warnings). Should we ? And if so, what would be the criterion ? To widen the scope here, I would eventually like to get to a point where master (or at least unstable) is always in an almost releasable state. All work that's not in that state should be on feature branches. That would then make any release we'd make a potential release candidate. But we're far from that IMO, because our test coverage is not sufficient to confidently assume big changes don't break other parts of the code. > 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. Indeed. I have been pondering this in the gnucash project. A 3 number versioning scheme that adheres to this would also mean we'd need not one but two maintenance branches: one for bugfixes and one for backwards compatible new features. (And all bugfixes would be upmerged into the the backwards compatible new features branch but not the other way around). Given the small size of our team I'm not sure the extra effort would be justified for the net gain. If gnucash were a public library I would probably more conservative. Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
