Beyond 2.8 - some design thoughts

Geert Janssens geert.gnucash at kobaltwit.be
Fri Dec 29 11:20:56 EST 2017


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


More information about the gnucash-devel mailing list