I don't really see a point in branching at this point. We have so few commiters and commits that having to maintain separate branches is at this time unwarranted. If this becomes an issue in the future I would address it at that time.
Vladimir On Tue, 27 Mar 2012, Daniel Pocock wrote: > 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
