Ok, based discussions, here is an amended proposal. Comments + votes much appreciated!
------------------------------------------------------------------------------ Once we do the 1.0beta release, I propose we do the following: * Stop actively developing on master. Instead, master should be periodically 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 (code name: 'community development branch') * Make a branch, release-branch-1.0, to which we only commit bug fixes (pulled from community development branch) We should also elect a release manager. The release manager should have the following duties: * Take responsibility for bringing commits from the community development branch to the release branch. The release manager can opt to do it themselves, or can ask for community assistance, at their discretion. * Make release announcements to the mailing list, including lists of bugs fixed. * Tagging the master branch with the release and release candidates. * Building the pre-release tarball, testing it, and putting it somewhere accessible. * Determining if any other release processes are necessary and bringing them up on the list. * Documenting their steps so that somebody else can be release manager later. --------------------------------------------------------------- If the above proposal passes, then it raises the following items: --------------------------------------------------------------- SUB PROPOSAL (A): What should we name the community development branch? Ballot: [ ] integration [ ] unstable [ ] trunk [ ] Other: ____________________ (write in candidate) --------------------------------------------------------------- SUB PROPOSAL (B): Who should be the release manager? [ ] David [ ] Seb [ ] David and Seb settle the question with dueling water pistols at sunset on the OpenGeo roof deck. [ ] Other: __________________ (write in candidate) --------------------------------------------------------------- On Thu, Jul 29, 2010 at 11:25 AM, Sebastian Benthall <[email protected]>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" > > * 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. > > If the above proposal is accepted, then I would nominate David as 1.0 > release manager. > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > -- Sebastian Benthall OpenGeo - http://opengeo.org
