[Crossfire-wiki] [Crossfire DokuWiki] page added: crossfire_release_cycle

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:



Date        : 2006/08/15 02:07

User        : mwedel

Edit Summary: created



This document describes the crossfire release cycle - what goes in each re
lease, 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 CVS branch contains what will be the next majo
r 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 stabl
e-major branch, as stable-major-minor.

   * The RE may choose to make a branch for an upcoming minor release to l
imit 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 o
ption.

   * All releases will be symbolically tagged as rel-major-minor-micro

   * There is no practical upper limit to minor or micro versions - crossf
ire 1.16.22 is valid.

   * Client and server releases will be done at same time, with matching v
ersion numbers.

     * Exception is micro releases, where it may be only the client or onl
y 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 com
ponents of crossfire.



=== What goes in each version of Crossfire ===

   * All changes go into the main head branch, what will become the the ne
xt 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, desc
ribing the feature, why it is important, and in broad terms, how it will b
e done.

       * All changes to protocol must have a design doc, no matter how sma
ll.

       * 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 p
eriodic 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.





IP-Address  : 209.204.178.229

Old Revision: none

New Revision: http://wiki.metalforge.net/doku.php/crossfire_release_cycle



-- 

This mail was generated by DokuWiki at

http://wiki.metalforge.net/