wiki:data:pages:crossfire_release_cycle
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
wiki:data:pages:crossfire_release_cycle [2024/05/23 18:03] leaf Remove wiki-data version of crossfre_release_cycle page |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | 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. | ||
Page Tools
