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
