This document describes the crossfire release cycle - what goes in each release, how often releases are made, repositories, branches, etc.

=== Crossfire versioning is described as major.minor.micro ===
   * 2.3.4 means major version 2, minor 3, micro 4
   * The main (head) of the SVN 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
     * Feature set of next major release will evolve over time, based on periodic mailing list discussion.  Items may be added or removed.
     * 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.