[crossfire] Crossfire Release Cycles/Methodology

[Mark Wedel]

Per the recent discussion on code reorganization and what goes in what
release, this document is an attempt to gather the points raised and make it
into a formal document that can be included in the code or put on the wiki.

This document does not attempt to justify or explain why different things are
done for reasons of brevity - if we actually want every developer to read it,
we want to stick to the what the rules are, and not as much how we arrived at
those rules.

If I missed anything, or there is strong disagreement on any of these points, 
speak up.
.

------------------------------------------------------------------------------

- Crossfire versioning is described as major.minor.micro
   - 2.3.4 means major version 2, minor 3, micro 4
   - The main (head) of the CVS branch contains what will be the next major
     release.
   - A branch for the minor releases will be made when a major release is done
     - It is from this stable-major branch that future minor releases are made.
     - If a micro release is necessary, it will be branched from the
       stable-major branch, as stable-major-minor.
   - The RE may choose to make a branch for an upcoming minor release to
     limit changes, as stable-major-minor.
   - Minor releases will be made at periodic intervals (2-4 months apart).
   - Micro releases will only be done if an immediate release is necessary
     due to a critical bug, and waiting for the next minor release is not
     an option.
   - All releases will be symbolically tagged as rel-major-minor-micro
   - There is no practical upper limit to minor or micro versions -
     crossfire 1.16.22 is valid.
   - Client and server releases will be done at same time, with matching
     version numbers.
     - Exception is micro releases, where it may be only the client or
       only the server released.
   - Public servers expected to run the stable branch, not the head branch.
   - stable branch will be made for all arch, maps, client, and server
     components of crossfire.

- What goes in each version of Crossfire:
   - All changes go into the main head branch, what will become the
     the next major release.
   - Smaller features/additions will also be done in the stable branch.
     - Developer discretion on whether to make change to stable branch
       in addition to head branch
   - Bug fixes go in both branches.
     - Developer making bug fix responsible for updating both branches
   - Following changes can only be made in the head (next major) branch:
     - Changes that break compatibility
     - Changes that make signficant changes to the code.
     - Removal of programs (discontinue support for a client as an example)
     - Changing name of executables.
   - Feature set of next major release to be discussed by developers.
     - List of proposed changes sent to mailing list.
     - Developers comment, decide priorities on list of features for next
       major release.
     - For major features, brief design document needs to be written,
       describing the feature, why it is important, and in broad terms,
       how it will be done.
       - All changes to protocol must have a design doc, no matter how small.
       - Design doc must be done before changes are commited - no writing
         design doc after code is written
     - Major release is done when feature set is complete.
     - For 2.0, smaller list of features should be the criteria since this
       change of release strategy is happening later in the 1.x release cycle.

------------------------------------------------------------------------------
Open Issues:

- Should we switch to SVN?  Switching repositories at same time as switching
   what the head branch means would make the most sense.
- Need some way to drive development - need some way to make sure items
   on TODO list for next release get done, and that developers just don't
   work on cool features they want that may not match TODO list.