In my mind it doesn't. It just adds the job of merging down the line. I prefer to work on the trunk since that forces you to actually make things work and not defer changes since you have them sitting on a branch. I understand there are pros and cons to both approaches. I just don't see that as a problem that needs to be solved at this time. I would prefer we spent our time of fixing/improving things instead of process.
Vladimir On Tue, 27 Mar 2012, Daniel Pocock wrote: > On 27/03/2012 14:52, Vladimir Vuksan wrote: >> 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. > > > Actually, it is not about the number of committers > > It just makes organisation easier: we need to lock things down for a release > branch (e.g. 3.3.x series). The more features and other improvements that > `creep' into the releases, the more difficult the release cycle will be. > > If 3.3.5 is good, then no new features should be added to the branch (either > in monitor-core or web), only essential bug fixes. > > After a whole lot of new features accumulate on master, just do: > > git branch release/3.4 > git checkout release/3.4 > git tag -m 'Tag 3.4.0' 3.4.0 > > and the features get released in 3.4 > > ------------------------------------------------------------------------------ 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
