I would prefer to see trunk used for the main development, and branches for experimental stuff, but of course this changes over time.
What is important is that the currently active branch(es) and trunk are cleary documented on the web-site and in SVN - I've seen a STATUS file used for this, or perhaps a REAME. This file needs to be at the top-level of trunk (and the contents should indicate that the latest version is always in trunk) For a long while in JMeter the trunk was not where the main dev was taking place, and this caused quite a few problems (as it was also not well documented ...). S/// On 29/01/2008, Gary Gregory <[EMAIL PROTECTED]> wrote: > It seems to me that once a release is out, it should be in a branch for > maintenance, so we would have v1.4 in a branch that would source 1.4.x > releases. The trunk is for the next release 1.5 or 2.0. This allows for just > tiny well placed changes for bug fixes in 1.4 as 1.4.x releases. IMO, other > (major) changes should only happen in the context of a major (2.0) or minor > (1.5) release and are appropriate in trunk. Once the scope of the next > release(s) is decided, then you can decide whether you create a branch for > 1.5. IMO, the trunk is for the current high tech work, compatible or not and > branches for more targeted and well-defined goals. > > Thank you, > Gary > > > -----Original Message----- > > From: Phil Steitz [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 28, 2008 7:00 PM > > To: Jakarta Commons Developers List > > Subject: Re: [pool] trunk? > > > > Any other opinions on this? > > > > I want to clean this up. Backporting all of the changes in the 1.4 > > release branch will break some things in trunk, since the composite > > package uses the new contracts with incompatible changes. So I would > > like to do the following, which I am not sure how to do in svn, so > > would appreciate feedback. > > > > 1) move current trunk to a 2.0 branch > > 2) essentially copy 1.4 release branch to trunk, retaining history > > > > The idea here is that what is now in trunk should have been branched > > as 2.0. I could use merge to backport changes after moving only the > > composite package out, but this would mess up history on the 1.4 > > sources. I am not sure what the best way to accomplish 2) is and > > would appreciate comments. > > > > Alternatively, I could copy the 1.4 release to a "1.x" branch and > > leave trunk alone, temporarily dead. That would be the easiest, but > > does not seem right. > > > > Thanks in advance for feedback. > > > > Phil > > > > On Jan 17, 2008 10:12 PM, Phil Steitz <[EMAIL PROTECTED]> wrote: > > > On Jan 16, 2008 11:18 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > Is development back on trunk yet? > > > > > > > > Having it off on a branch worries me :) > > > > > > > > > > We need to make a decision on the 1.3/1.4-incompatible changes that > > > are currently in trunk, which should probably iteself have been > > > branched as 2.0. > > > > > > My preference is to move the composite package to a composite or 2.0 > > > branch and merge the 1.4 release branch back into trunk, reverting the > > > incompatible changes as in 1.4. > > > > > > Phil > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
