My 2ยข:
From a user perspective, I very much like the idea of a year.quarter
numbering scheme. One need never have to research the age of the release
they are using. (even those of us who know the cycle)
If non-compatible changes are kept on say, the ".1" or a year-based
boundary, that would make the upgrade path easy enough to follow.
Regards,
Adrien
On 11/14/22 12:59 PM, john wrote:
But what about the opposite approach, having only one permanent branch and no
major releases? Instead of 5.0 next spring we'll release 2023.1 and the spring
after that 2024.1, with .2 in June, .3 in September, and .4 in December every
year? Major changes, like c++options, get merged when ready; we might do a beta
release (e.g. 2023.2beta) a month before a release with a major change to get
better user testing. We'd have to work out policies for API and schema changes
because it would blow up the file upgrade path for users who've skipped some
releases. There's a very dense exposition on this pattern at
http://dymitruk.com/blog/2012/02/05/branch-per-feature/.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
