Pull freeze

[Brad Anderson]

On Wednesday, 1 August 2012 at 17:04:06 UTC, David Nadlinger 
wrote:
> On Wednesday, 1 August 2012 at 11:56:48 UTC, Andrei 
> Alexandrescu wrote:
>> Well this doesn't do a lot in the way of substantiating. I do 
>> want to be illuminated. I want to get DVCS! And my 
>> understanding is that we need to branch whenever we plan a new 
>> release, and cherry-pick bugfixes from the mainline, and such.
>
> Disregard what I said about cherry-picking – while it would 
> work, I was thinking too much in terms of SVN here. With Git, 
> the better choice usually is to make all the commits which 
> should end up in the release directly on the release branch, 
> and merge that branch periodically back to master. If all the 
> commits from the release branch should also make it into 
> master, which is usually the case, you don't end up with two 
> logically separate commits in the same repository this way.
>
> David

Yeah, this is exactly how it should be done. cherry-picking 
should only be needed in very special cases, not as part of a 
regular workflow.

Basically like this:

1. Walter posts the usual "Time for a beta" message and does 
`checkout -b release-2.061 master` and `git push origin 
release-2.061` to put it on GitHub.

2. During the beta period as people find regressions and bugs 
that must be fixed before release they make pull requests 
targeting release-2.061 instead of master. People doing regular, 
non-release-blocking changes just target master as usual.

3. Once the final release is made and out the door a tag is made, 
release-2.061 is merged into develop and deleted: git checkout 
master; git merge release-2.061; git branch -d release-2.061; git 
push origin :release-2.061 (this is all safe to do, git prevents 
you from deleting branches with unmerged changes by default).

If master does need bugfixes from the release branch (I think 
this would be rare) you can merge the release branch or 
cherry-pick. Either works fine. This solves the freeze problem 
(to be honest, I don't think the freezing problem is really that 
huge of deal).

I still think a more important change is using feature/issue 
branches instead of committing partial work to master. master 
should always be in a position where it's ready for a release, 
even if some project someone is working on isn't ready yet (and 
this is mostly the case now due to the nature of GitHub).