@tsteur opened this Issue on September 22nd 2021 Member

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?

@sgiehl commented on September 24th 2021 Member

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

@heurteph-ei commented on September 24th 2021

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.
(From Atlassian)

(Note: initially I wanted to suggest GitFlow, but I saw that it was "a legacy Git workflow")

@tsteur commented on September 26th 2021 Member

@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 next_release to 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

  • When there is RC then release manager creates branch next_release off 4.x-dev (can be done command line or Github UI)
  • Trigger RC off that branch
  • Week later trigger release off that branch
  • Create PR next_release -> 4.x-dev if there were regressions (clicking a link to create PR)
  • Delete the branch
  • ... if there is a patch release needed repeat process but create next_release off the branch from the release...

And this would avoid

  • Accidentally merging any PR after an RC was released
  • Accidentally merging any feature after a release was released (as in a patch release this should only include regressions)
  • Not being able to merge for 10-14 days (1 week for the release, and 4-7 days after a release)
  • merge conflicts between the different PRs as in a 10-14 day period a lot of PRs may be created (especially annoying when there are merge conflicts for UI tests as you need to merge 4.x-dev into the PR, then run tests, then fix tests, ...)
  • As a developer you don't need to check every time whether things can be merged currently or not.

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.

@tsteur commented on September 26th 2021 Member

Thanks @heurteph-ei for the link I'll check it out

@tsteur commented on October 7th 2021 Member

We try this for a while and then assess if it needs changing

This Issue was closed on October 7th 2021
Powered by GitHub Issue Mirror