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).
