See our current process for releases: https://developer.matomo.org/guides/release-management
Before releasing a new version we release an RC. As soon as an RC has been released we only merge regressions. ... We usually run the RC for a minor release for at least a week, for major releases multiple weeks and for patch releases at least one day but better multiple days. ... Once a new release has been released we wait for three days with merging PRs in case we have to do a patch release.
That effectively means if we release eg monthly then there are around 8 working days or so where we can't merge. With quite a few devs in the team this is not really practical anymore as more merge conflicts will come up, more conflicts around tests etc.
Ideally we don't have a period where we can't merge anything.
A solution could be to create a branch once we have release release candidate and then merge important bug fixes / regressions in there while we continue the work on the
4.x-dev already for the next release after that one. After the release we could be merging all changes from that branch into
4.x-dev. Branch name for important bug fixes for the release could be something generic like
next_rc (or for simplicity
next_release) or more specific.
If there are any regressions, then we could also create a new branch from the actual release and only merge important bug fixes into that branch. Once the patch release has been done we could merge those changes into the
4.x-dev release again. Branch name could be something generic like
next_patch_release (or for simplicity
next_release) or more specific.
Any preference / objections / ideas around that?
@tsteur I guess creating a branch whenever we need a new release due to regressions should be fine. But actually I'm not yet sure if not merging any new feature for a couple of days, like we currently did, would be a big problem. When a version has been released we usually would start working on the major issues of the next milestone, which might even take some time in development and review. Maybe we could simply try to keep the current behavior and maybe switch it if if makes any problems...
What about Trunk-Based Development? See https://trunkbaseddevelopment.com/
Summary: Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. Since it streamlines merging and integration phases, it helps achieve CI/CD and increases software delivery and organizational performance.
(Note: initially I wanted to suggest GitFlow, but I saw that it was "a legacy Git workflow")
@sgiehl we could see over time indeed. It's just while we onboard over the next few years and more and more devs join there are also many working on smaller issues and it always takes bit extra time to know which ones can be merged and merge conflicts etc. I'm assuming we'll release an RC today or tmrw for a week and there are currently quite a few of PRs waiting to be merged. And usually we don't even expect any regressions needing to be merged after an RC was released (maybe translations or so but not too important maybe).
In the past we also had the every time the problem that often after an RC PRs were still merged which this would prevent.
I'm assuming it be minimal overhead to try this maybe once or twice and see how it goes? I suppose the overhead of doing this be mostly for the release manager to trigger a release from a different branch. And then we can use github to create a PR from eg
4.x-dev and if there are no merge conflicts and tests pass then the PR can be merged quite easily. In other cases there might be a bit of work but this work we would also have likely if we were holding PRs back.
What I was meaning
4.x-dev(can be done command line or Github UI)
next_release -> 4.x-devif there were regressions (clicking a link to create PR)
next_releaseoff the branch from the release...
And this would avoid
Overall I reckon it could be good to try as currently it is bit of a problem. Some problems may go away in say 6 months but if we onboard more developers etc then it might be there again.
We try this for a while and then assess if it needs changing