| abstract
| - 1. Freeciv Release Cycle begins when previous version is branched to its own stable branch. Part of that branching process is setting new version numbers and other version specific things to master. Version number is initially of form ".90-dev" but can be increased during the development all the way to ".99-dev" (but it's usually a good idea to save some numbers for the next phase too) After that master is open for development of the features of the new version. This phase lasts at least one year. Master is always in development build mode, meaning that many extra debug and sanity checking features are turned on to catch problems from the new code as soon as possible. 2. The new version itself is branched (Development Manager) New version continues development in stable branch. Only select new features can go in, while rapid development takes place in master for next release. Goal in the stable branch is to mature the features already in. Newly created branch remains in development build mode. Version label is changed to "-alpha" 3. Datafile format freeze (Development Manager) Formats of the custom content files used by the new version are declared frozen. After this point all revisions from the branch are compatible with same data files. Modders can start producing mods for the upcoming release knowing that mods compatible with current revision will be compatible with the release. Version number is set to match the upcoming release ".0-alpha" 4. Network protocol freeze (Development Manager) Network protocol between freeciv server and client is declared frozen. After that point any client revision can work together with any server revision from the same branch. Branch is switched to beta build mode, mainly meaning that running the programs emits extra warnings about it being beta quality. Version label is changed to "-beta0" 5. Development Manager (currently cazfi) hands main responsibility of the branch to Release Manager (currently jtn). This may take place at the same time as Network protocol freeze (freeze will prevent a lot of further Development anyway), but can also be a bit later. When handing responsibility over, Development Manager should have collected list of changes since previous branch to help in writing of NEWS. 6. First beta (Release Manager) Followed by as many betas as necessary to reach release quality. Version labels are updated to match beta number 7. First Release Candidate (Release Manager) What is assumed to be content of first stable release from the branch. If serious issues are found from RC before stable release, new RCs are issued until one works. Version labels are update to match RC number. 8. First Stable Release (Release Manager) Followed by many more. There's no version label. 9. Abandoning the branch. At some point, usually a bit after first releases from the next version are already out, it's decided that no more releases from the branch will be made, except if needed to fix security vulnerabilities or other very serious issues found after that point.
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)