Re: [GNC-dev] Git branches
Adrien Monteleone <[email protected]>
| Newsgroups | gmane.comp.gnome.apps.gnucash.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel