I've created a new branch in git for 3.3 releases:
https://github.com/ganglia/monitor-core/branches/release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git pull Already up-to-date. daniel@lt2:~/ws/ganglia/ganglia-git$ git branch release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git branch * master release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git push origin release/3.3 Total 0 (delta 0), reused 0 (delta 0) To ssh://g...@github.com/ganglia/monitor-core.git * [new branch] release/3.3 -> release/3.3 Further 3.3.x releases should be made from the branch, and tags should be made on the branch (I've updated the release procedure with comments about this) Any bug fixes or new features should continue to go on master, and then they can be selectively merged into the release branch if necessary. I would propose that the merge policy is not too restrictive: while a tarball is in release candidate status (e.g. 3.3.5 at present), only the release manager should merge/backport from master. At all other times, any committer can merge bug fixes onto the release branch. I'd also propose the same for the web repo, but I haven't created any branch there yet as I'd like to get feedback on the strategy first ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
