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. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
