On Mon, Apr 15, 2019 at 12:35 PM Sorabh Hamirwasia <[email protected]> wrote:
> ... > > @Ted Dunning <[email protected]> - I am not sure if I understood > correctly but I think the reason master is locked and two active branches > are not chosen is to reduce the overhead of cherry-picking commits from > master to release branch. And also if master is not locked then the > scenario which Arina mentioned can still happen if a required commit for > 1.16 is between 2 commits intended for 1.17 only. > > For now *** Please treat master branch as locked and don't merge any > commit until further notice *** > Yes. I get it. I understand the lock motivation. That means that master is effectively a 1.16-RC branch. Somebody who needs to commit changes to 1.17 will (should) create a 1.17 branch from which they will eventually cherry-pick commits back to master. At the very least, they will have a private copy of master that is effectively a separate branch that they will have to rebase as changes go on to master to get the release in shape. This means that there *will* be at least two branches. Probably more than two since there is no formal place to put the 1.17 changes that are pending. As such, I would suggest that making this situation explicit and public would be easier for people. It would help people to either create a 1.16 branch, committing fixes there for RC problems and cherry-picking to or from master as needed OR create a 1.17 branch and use master as the 1.16 branch (which is a bit confusing because it changes peoples normal procedures). Neither strategy requires that master be locked. The former leaves master as the place all new stuff goes. The latter follows the "all development on a branch" orthodoxy.
