On 07/29/2010 11:25 AM, Sebastian Benthall wrote:
We will soon be tagging a 1.0beta release and publishing the tarball
for the release.
Something I don't think we've talked about much is how development
will proceed on git branches after that release.
I'd like to propose to propose a plan of action for team
consideration, referring to this blog post David sent out earlier for
reference:
http://nvie.com/git-model
Once we do the 1.0beta release, I propose we do the following:
* Stop actively developing on master. Instead, a 1.0 release
manager should be chosen to pick when master should updated with a
pointer to the improved release branch. (I'd expect this would happen
at official release candidate stages, and then the final 1.0 release)
* Continue active development of features not meant for 1.0 on a new
branch. We could call it 'develop' like in the blog post but out of
svn nostalgia and because I think it's weird to give a branch a name
that's a verb I'd be +1 calling it "trunk"
I don't think it's a great idea to use Subversion terminology in git.
"git revert" and "svn revert" are very different things, and in general
trying to think of git as "subversion with extra knobs" is a recipe for
shooting yourself in the foot. In this case, 'trunk' and 'master' are
just conventions so there's less potential for damage. But I'd still go
for "integration" (it's the branch where we are bringing all the new
features together) or "unstable" or something rather than "trunk".
* Make a branch, release-branch-1.0, to which we only commit bug
fixes (pulled from trunk)
In addition to the above proposal, I'd be +0 on the release manager
being the person responsible for bringing commits from trunk into the
release branch. I think that should be up to the release manager though.
What does the release manager do if he is not playing gatekeeper for the
release branch?
If the above proposal is accepted, then I would nominate David as 1.0
release manager.
--
Sebastian Benthall
OpenGeo - http://opengeo.org
