Isn't that what branches are there for in the end? Seems reasonable to me..
Robbie > -----Original Message----- > From: Ken Giusti [mailto:[email protected]] > Sent: 19 January 2011 18:27 > To: [email protected] > Subject: RFC: svn branching for new feature development > > Hi all, > > I've been working on the C++ broker flow control feature that I QIP'ed > about last week. I'm planning on having the feature complete in time > for the 0.10 release. > > My concern is that I've been making a number of changes in my local > sandbox that are, well, _local_. I'm just a dropped laptop or a > spilled bottle of NightTrain away from losing all this work. > > Actually, I've been working in an git clone of the apache/qpid git repo > on github - so my changes are safe. But what I'd really like to do is > develop this off a branch on the qpid trunk. Couple of reasons: > > 1) better visibility to other qpid developers - no need to track my > github repo. > 2) better history with respect to merging from trunk. > 3) we can better control the introduction of this feature into trunk > with respect to the release schedule. > > Would it make sense, in general, to allow developers to create branches > for the development of new or possibly disruptive features? We could > leave it up to the release manager to make the go/no-go call for > merging the branch prior to the alpha release. > > Opinions? > > -K > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
