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

[will]

So...  I thought it was a good idea to do future development in the 
trunk and then merge 1.1 changes down to the 1.0 branch.  I'm regretting 
that at this point.

The the problems are four-fold:

1. It requires a lot of non-trivial merging.

2. We'll have to maintain translations for multiple branches--which is 
potentially more work; bdk mentioned we could write a script to merge 
translations and figure it out, but I think this complexifies the matter 
enough that it could cause other issues that we'd spend time chasing down.

3. It makes our repository setup more complex for contributors.  It 
causes us to go through and update all of our documentation regarding 
which branch is for what development and keep these up to date (which we 
didn't do).  I've had several conversations with people trying to build 
Miro and having problems and then trying to explain that we're doing 
different development in different branches and ...  Too hard.

4. Nightlies and testing is more complex.  "svn nightly" in Bugzilla 
suddenly isn't useful enough--we need to know which branch the problem 
is in.


Matt spent a bunch of time adding support for building nightlies for 
multiple branches, but are we getting the same amount of testing for 
multiple branches?

The third problem could be fixed with a written explanation of the plan 
and better documentation.

The second problem could probably be fixed with additional scripts to 
manage translation merging and such or just making translators work on 
multiple translations.

The first is a problem whichever way the merging goes.

We've got a small number of developers still and a small number of "big 
changes" in the works, so I think it's better to optimize our time in 
regards to simplifying testing and production of new releases.  Thus the 
new plan...  (which is really the old plan before I suggested a terrible 
idea).


The new plan
============

We're thinking that the new plan going forward should be this:

1. The trunk is for development on "the next release".  Currently "the 
next release" is 1.1.  Following the release of 1.1 it'll be whatever 
the following release is...  1.2 probably.

2. The Democracy-Player-x.x branches are for maintenance releases.  For 
example, when we release Miro 1.1, then the Democracy-Player-1.1 branch 
will be for 1.1 maintenance--not for 1.2 development.

3. Any future development that isn't scheduled to land in "the next 
release" gets its own branch in the tree.  For example, bdk's work to 
split the front end from the back end is in branches/frontend-startup/ 
(to be renamed when he sees fit).  It's possible svnmerge will alleviate 
issues with this since merging will be in one direction from one source: 
the trunk to the branch.


Fixes for the 1.1 release
=========================

To fix the mild debacle we're in, we need to do the following soon:

1. Remove whatever changes that are in trunk that aren't going with 1.1. 
  I think this is limited to bdk's frontend separation changes.  Are 
Luc's build changes going with 1.1?

2. Update the documentation in the wiki to reflect the new plan.

3. Revert to doing nightlies on the trunk.

4. Revert to doing translations on the trunk.

5. Fix the version number on the trunk from 1.5 to 1.1.


Going forward
=============

1. Development for "the next release" is done in the trunk.

2. Development on features or other things that are not landing in "the 
next release" go into a branch.


Comments/suggestions?
=====================

Does this sound ok going forward?  What other aspects of development and 
releases are not accounted for in this plan?

Can we either get these changes done or figure out how else to fix the 
mild mess we have before tomorrow (Thursday - 12/13/2007) so that we can 
have all the pieces in place for finishing up the 1.1 release and 
getting it out next week.

/will