Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the release process so we can still merge PRs while there is an RC and after a release #18044

Closed
tsteur opened this issue Sep 22, 2021 · 5 comments
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Milestone

Comments

@tsteur
Copy link
Member

tsteur commented Sep 22, 2021

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 tsteur added the RFC Indicates the issue is a request for comments where the author is looking for feedback. label Sep 22, 2021
@tsteur tsteur added this to the 4.5.0 milestone Sep 22, 2021
@sgiehl
Copy link
Member

sgiehl commented Sep 24, 2021

@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
Copy link

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
Copy link
Member Author

tsteur commented Sep 26, 2021

@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
Copy link
Member Author

tsteur commented Sep 26, 2021

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

@justinvelluppillai justinvelluppillai modified the milestones: 4.5.0, 4.6.0 Oct 7, 2021
@tsteur tsteur added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Oct 7, 2021
@tsteur
Copy link
Member Author

tsteur commented Oct 7, 2021

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

@tsteur tsteur closed this as completed Oct 7, 2021
tsteur added a commit to matomo-org/developer-documentation that referenced this issue Nov 16, 2021
I was initially going to wait with documenting this but it looks like this works a lot better than it did before and we'll likely keep using it and if needed make mostly minor tweaks.

refs matomo-org/matomo#18044
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Projects
None yet
Development

No branches or pull requests

4 participants