I've worked this problem both ways, one where the codebase is copied into a
new repository (perforce-ism) and development continues on both tracks, and
the other where the main line is branched and changes in the head are merged
into the new version branch.
Branching makes sense when the bug fixes on the head can be reliably merged
into the branch over time. If the changes are big, then branching is a pain
and merges end up being done by hand rather than through CVS as the code
moves around or becomes obsolete.
I don't fully understand the scope of changes under discussion for James 3,
but it would be simpler to maintain one module and add the changes into the
existing codebase, replacing old components with the new hotness (like
Serge's mordred/dbcp switch). Not only is it simpler, it helps keep the
project grounded in reality, especially as more automated tests comes online
in the next few months.
A new repository works well under two conditions: there's good leadership on
both modules going forward and there's good team members on both tracks. If
the 2.x repository becomes orphaned and everyone is off working on 3.0,
there's a risk that fixes and improvements to the 2.x line will not occur
and the product will languish while everyone is working on the next big
thing.
So if a new repository is made, it would be wise to make sure that someone
takes on the 2.x leadership role to keep fixes and improvements to 2.x
coming to maintain product momentum.
Matt Bishop
[EMAIL PROTECTED]
"We are all here on earth to help others. What I can't figure out is what
the others are here for."
- W. H. Auden
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
