[GNC-dev] Git branches

[Geert Janssens]

Op maandag 14 november 2022 19:59:24 CET schreef john:
> I guess we could do that as long as we continue the no-backports policy, but
> it's something you argued against when we started using git-flow a few
> years ago.
> 

I don't have a clear memory of what I argued against way back then. It doesn't matter much. 
In reality we have continued to avoid backporting anyway, which is just fine for the small 
team that we are.

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

It's actually a branch and release pattern I had been considering but was hesitant to bring 
up as perhaps to radical. Since you now bring it up for consideration, let's evaluate it after all.

1. I like the idea of only a single release branch and all development happening on feature or 
bugfix branches that get merged into this release branch when ready. 

2. I also like the idea of dropping distinction between a stable and development series. It 
would bring improvements to users much faster in general - it will be released when ready, 
not queued for the next major release (which could be only in 2 years worst case).
It's a bit what fast moving projects such as webbrowsers currently do.

3. Year based release numbering is also very clear. And always gives a reasonable indication 
of how old a given version of gnucash is.


On the flip side
1. This does do away with semantic versioning completely. But that's the whole point of 
having only one release branch. Each release can be a mix of bugfixes and new features.
2. I imagine this only works well if newly added code (features or bugfixes alike) is well 
tested, implying having tests written for it. And that the existing code base is well tested as 
well. While slowly improving, the gnucash code is still not very well covered.

I also read through the dymitruk article you linked to. There are a few other elements that 
are not fully clear to me yet:

* he talks about an integration branch. Is that a branch that people continue to merge their 
new work in, and that just serves 
a. to discover and resolve merge conflicts early on and
b. to run an integration test suite on
Will this branch ever be cleaned or just merge upon merge be added to it ? I have no clear 
example of how such a branch is used really.

* there's a separate release branch. Which can be reset from time to time if bad features are 
to be skipped for the most recent release. Resetting a branch seems to conflict with 
distributed repositories in my mind. But perhaps this is not a problem if it's commonly 
known this a a resettable branch. And no devs except for the release manager should really 
check out this branch and then even only while preparing for releases ? It's a bit vague to 
me.

* handling merge conflicts and sharing the resolutions seem to be an important part of the 
solution. Otherwise these conflicts continue to trip up different devs. There was a suggestion 
as to how to do this, but nothing concrete. Something to figure out as well.



As for the API and schema changes, that would indeed require some reconsideration. 

I have a few first thoughts, but nothing well structured:

* For API the important change to keep in mind is deprecation. New API won't be an issue.  
Do we support function signature changes or should a new function be defined in that case ?
Current policy is that we deprecate in a stable series and remove in a future major release. 
As our current schedule is a two-year cycle for major releases, we could make the policy "a 
deprecated feature/function will be kept around for 2 years, after which it will be definitely 
removed". Other durations can be chosen as well, as long as it's clear. So consumers of the 
api could at most jump two years ahead from the version they currently use with a 
guarantee their own code continues to work. At that point they should do the work of 
updating their code to cope with deprecated api.