I support your idea. Making branches for new feature development is a common practice.
Were you thinking of doing it for every single change request, or only for big ones? On Sun, 15 Jan 2006, Greg Wilkins wrote: > > I would like to create a dev branch to start working on some > 1.1 and 2.0 stuff. > > But I don't think it is appropriate to pollute /branch with > private branches as it will be good to be able to go there and see > all the official branches: > > /branch/1.0 > /branch/1.1 > > without seeing > > /branch/djencks > /branch/gregw > /branch/dain > > etc. etc. > > So I would like to propose a secondary location for development > branches /devbranch. > > Moreover, I don't think that development branches should be > considered private branches as this would encourage many branches > and discourage cooperative development. I think they should be named > for the features they are trying to develop. So we would have > things like > > /devbranch/servlet-2.5 > /devbranch/openejb-3 > /devbranch/kernel > > > I think the policy should be that anything targeted for an > x.0 release should be developed in a /devbranch. > > Anything for a x.y branch can be developed in /trunk or > in a /devbranch if it's development may take longer > than a single x.y cycle or if it's inclusion in an x.y > release is up for debate. > > Anything for a x.y.z branch can be developed in trunk but > should be stabilized in the /branch/x.y > > >
