User Tools

Site Tools


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.
crossfire_release_cycle.txt · Last modified: 2006/11/15 11:48 (external edit)