Traditionally, that's trunk!

Try things out in trunk.  Get feedback.  When a new release is planned,
"pullup" the specific release features into a fresh branch (trunk to
branch is "up").  The branch log is an annotated list of the new features.
Requires actual planning and coordination of a release, paying attention
to all the "depends" part of the report tracker....

In the alternative, test each feature in its own branch.  When it's
baked, commit the entire set to trunk with one subversion command
(there's direct support for this in subversion).  I tried that with a
series of changes to 2.1, and got reamed by Per for not committing each
and every change separately in parallel to all branches.  (heavy sigh)

Anyway, the latter technique is how I've been developing things locally.
With separate checkout of the tree, make all the changes, and then
create the patch and apply to the branches.  Tedious.  I'm at 7 complete
trees at the moment, been as high as 15.  Hard to keep up-to-date.

In summary, a *plan* would be nice....

_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to