[Develop] trunk and branches - the new (old) deal

[will]

Hrm....  I agree with a lot of what you're saying, but I think we don't 
have enough people working on the project to manage a more complex workflow.

So...  say we don't go with reverting the workflow to "trunk is for the 
next release", how do we get to 1.1 from here?


Nick Nassar wrote:
> As someone working on what would go into a "big change" branch, I have a
> big problem with your proposal.
> 
> As I understand it, your proposal basically comes down to moving the 1.x
> "stable" branch to trunk and moving major new features go into their own
> branches.  Instead of doing this, I think we should go with your other
> suggestions of adding support for building nightlies from multiple
> branches to our scripts, better documentation, and writing scripts to
> automate translation work.
> 
> 
> I think we still need an "unstable" branch that contains all of the new
> features.  I don't want to split the trunk branch into lots of different
> unstable branches.
> 
> I'm working on major UI changes that will be too unstable to include in
> trunk for a long time, will need some testing early on and lots of
> testing towards the end of their development, and integrate closely with
> other "big change" branches.
> 
> Your proposal will make life easier for the 1.x releases in the short
> term but make adding new features more difficult.
> 
> Going through each of the problems you have with the current system.
> 
> Merging. Your proposal creates more merging problems for experimental
> branches.  We'll have to periodically merge in changes from stable, then
> make a giant merge once our experimental branch is done.  Then, all the
> other people working on experiemental branches will need to merge that
> giant merge into their experiemental branch. So, what would have been
> lots of little merges will turn into several large non-trivial merges.
> It also means that stable will get blasted with large changes all at
> once.
> 
> Translations. With your new proposal, experimental branches just don't
> get translated.  That means if there's an i18n problem, I don't know
> about it until my code has been merged into the stable branch. That's
> worth the trouble of uploading two sets of translations to launchpad
> instead of one. If time spent uploading translations is a problem, one
> of us should just write a script to automate it.  If a string in one
> branch is translated, launchpad is smart enouogh to suggest that same
> string for the other branch, so this won't cost ours translators too
> much time either.
> 
> Repository Complexity. I don't think your proposal makes things less
> confusing for contributors.  It's a common convention that trunk is
> "unstable" and stable versions are kept in branches. Also, having
> separate branches for each features makes it difficult for people who
> want to test or develop these new features. They have to know what
> branch their feature is in.
> 
> Testing and nightly builds. I want people to start testing my new
> features before they're stable enough for the general public, and I want
> them to be tested with other major features so we catch unexpected
> interactions early. Your proposal makes that impossible.  If having a
> "stable" nightly and an "unstable" nightly is causing trouble or
> confusing, one of us should spend the time to fix it.
> 
> What does everyone else think?
> 
> Nick