+1 to Simon's view point. I also see this good from one of our earlier objective to keep our trunk stable. I'd prefer that we evolve the (potentially breaking) changes that we want to do in our road to 2.0 initially in a branch.
Just a worry - would it be challenging to keep the branch and trunk in sync from a feature enhancements perspective. i.e. if there are some feature enhancements that go into the trunk then we have to ensure that equivalent ones go into the branch smoothly riding over the changes that have happened in there. - Venkat On Wed, May 14, 2008 at 3:31 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > Simon Laws wrote: > > > > > snip.... > > > > > > > > > I prefer a branch to make it clear that all in the community can work > > > > in > > > > it, to make it clear that it's accepted by the project, that it's > > > > buildable > > > > etc, instead of having work buried in the middle of a sandbox > together > > > > with > > > > obsolete or broken stuff, with an unclear status. > > > > > > > > > > > So you mean a branch for 2.0 (you did say this in your previous post > and > > > my > > > eyes skipped over it) and trunk would remain as 1.x ? > > > > > > Simon > > > > > > > > It doesn't really make a difference for me: just 2 folders, one for 1.x > > one for 2.0, and just make clear which one is which and what's its > purpose. > > > > I'm fine with whatever option people prefer: trunk for 2.0 and > > branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, > > whatever keeps our community happy. > > > > -- > > Jean-Sebastien > > > > Given the amount of activity we have going on in trunk at the moment, I > would support 1.x remaining as trunk and cutting a branch to allow for more > innovative (read breaking) development in a 2.0 code stream. > > Simon >
