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
Comments
@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/
(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 What I was meaning
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. |
Thanks @heurteph-ei for the link I'll check it out |
We try this for a while and then assess if it needs changing |
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
See our current process for releases: https://developer.matomo.org/guides/release-management
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 into4.x-dev
. Branch name for important bug fixes for the release could be something generic likenext_rc
(or for simplicitynext_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 likenext_patch_release
(or for simplicitynext_release
) or more specific.Any preference / objections / ideas around that?
The text was updated successfully, but these errors were encountered: