Slash'EM development

Development cycles

Slash'EM development works in cycles based on the following phases:

1. Feature stuffing. In this phase we try to add as many cool new features to the game as we can. We use the list of requested features as a source of ideas along with whatever ideas the dev-team may already have. We run these ideas past the slashem-devel mailing list and ask members to comment and/or vote on them. This helps us to improve the ideas before they get implemented and to decide what features are more desirable to the players (many of the dev-team members don't get to play Slash'EM anything like as much as some of the player members of slashem-devel). During this phase, the version of Slash'EM which is being created is known as experimental and isn't normally released (although source tarballs which are auto-generated from CVS are available).
2. Internal testing. In this phase we try and rationalise the feature set and fix any serious bugs which make the game totally unplayable. We rely heavily on members of slashem-devel to test the game. During this phase, the version of Slash'EM which is being created is known as development (alpha). Releases are made but aren't normally advertised widely. Typically, the website will list the release and an announcement will be made to the slashem-announce mailing list.
3. External testing. Once it seems as though the game is broadly playable and feature-stable, we enter beta-testing and ask the general Slash'EM playing population to test the game. Releases are announced to the wider community via freshmeat and other third-party websites.
4. Stability. Once the bugs being reported have died down to a set of relatively minor matters and the number has reduced from a flood to a trickle we declare the next version to be stable. From this point on we try very hard not to make any changes that would cause save/bones files to be incompatible.
5. Maturity. Eventually, the next version of Slash'EM is declared stable and all development on the previous version ceases. At this point it is considered mature.

Note that development cycles run in parallel. We normally have two versions on the go at the same time; one stable and one development. Versions in the same development cycle share the same major, minor and patch levels (the first three numbers in a version number, separated by decimal points). The editlevel is shown with an E suffix. The edit level is increased for an incompatible or feature change. Finally, the fix level is denoted with an F suffix (neglected for fix level 0) which is used to distinguish bug-fix versions.

CVS branches

CVS uses the concept of branches to implement parallel development. The idea is that there is one main branch which always contains the source for the latest developmenty cycle and branches off this which contain the source for earlier development cycles. This would mean that changes to earlier development cycles would be lost so normally changes to earlier development cycles will also be made to the main branch at the same time. CVS branches are named after the development cycle to which they belong.

On the basis that a picture is worth a thousand words, we present a very bad ASCII diagram:

          /====== SLASHEM_RANGER (development cycle 0.0.6)
         /
        /   /====== SLASHEM_VAMPIRE (development cycle 0.0.7)
       /   /
=================== main (development cycle 0.0.8 and beyond)

You can find information on how to use CVS here.