The master/stable problem
We actively develop in master
. When RC1 gets created, we create a stable
branch (let's use 8-4-stable
for this example) off of master that then becomes the sole source of 8.4 and all of its patches.
The problem now, obviously, is there's a split. There are pending merge requests intended for 8.4 (and thus 8-4-stable
) that are still using master
as their target branch. When these are merged, someone (the release manager) has to make sure they make it into 8-4-stable
.
That happens one of two ways:
One
They get merged into master, and before a release we git merge master 8-4-stable
.
Pros: Easy, clean, fast, nothing gets missed by accident.
Cons: This "freezes" master
for active development of 8.5. Everyone has to be made aware of when the freeze starts and when it ends.
Two
They get cherry-picked.
Pros: master
is available for merges beyond the current release.
Cons: The release manager must be made aware of every merge request that needs to be picked. Depending on how soon we did RC1 and how many merge requests are pending, this can be a lot of work, and is prone to human error. The author and/or reviewer of any pending merge request now has to be aware that master
is no longer safe to merge into their branch, or to rebase against, to pull in the latest changes to resolve merge conflicts or fix tests.
Dmitriy prefers option two:
dzaporozhets [4:23 PM]
I am wondering how we are going to manage this code freeze
with growing company + contributors it might be a problem
I think after stable branch created - development should go in master to avoid development “freeze” for few days
imagine when we get to 50 devs :simple_smile:
its impossible to notify everyone not to merge or push into master for several days
rspeicher [4:26 PM]
The thing I worry about is that we don't have a set time for when the stable branch is created,
so for example I'm sure we've merged stuff for 8.4 this morning _after_ stable was created that
is in master but I was never cc'd on, and without another merge from master it will be left out
of stable
dzaporozhets [4:27 PM]
for example. If stable branch exists you must cc release manager or create MR to stable branch.
Otherwise your change wont be included
its much better then dead lock on master branch
> without another merge from master it will be left out of stable
I think its more acceptable then branch freeze
at least it scales easily
what do you think?
rspeicher [4:30 PM]
I just get stressed out about shipping a new version and something's left out and people are
going "What! I thought that was merged!" :simple_smile:
Tomasz is an example of the other side:
tmaczukin [5:35 PM]
Look at this MR https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2264/commits
I've merged master at 7pm (CET). After You've posted the stable workflow I've reseted this branch to
the last commit before that merge and then cherry-picked other commits.(edited)
Ok, so what should be the workflow in that case? This MR is planned for 8.4, but we cant accept MR by
GUI [due to merge conflicts with master]. Release manager should merge it manually?
And after that cherry-pick all commits to `8-4-stable` or I should open a MR from this branch to
`8-4-stable`?
rspeicher [5:44 PM]
Probably safest to rebase off 8-4-stable and edit existing MR to use that as target branch
tmaczukin [5:45 PM]
`8-4-stable` will be merged to `master` after publishing release?
rspeicher [5:45 PM]
Or I'll pick it, I dunno :simple_smile:
tmaczukin [5:46 PM]
If we merge it only to `8-4-stable` then it will disappear in future release :stuck_out_tongue:
[5:47]
And I have three more MRs like this one :wink:
rspeicher [5:51 PM]
Change the targets to `8-4-stable` and as each one gets merged, ping me and I'll pick to master
tmaczukin [5:53 PM]
OK :simple_smile:
What if we could merge master
into 8-4-stable
at-will up until the 22nd, at which point 8-4-stable
only gets updated via cherry-picks for patch releases. At the same time, 8-5-development
(or something) can be a playground where anything goes, and which pulls in master
as-needed, and then after the 22nd gets merged back into master
and deleted, and the process starts all over?
I think up until the 22nd, the majority of devs are working on MRs for the current release -- future releases are the minority. Maybe that's anecdotal.