crossfire_release

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

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.

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.