Back to the Slash'EM homepage
Slash'EM development works in cycles based on the following phases:
- 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
- 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.
- 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.
- 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.
- 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 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