[GNC-dev] Git branches

[Adrien Monteleone]

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/.