| Prev | Chapter 8. Engineering Standards | Next |
|---|
OpenACS version numbers help identify at a high-level what is in a particular release and what has changed since the last release. A "version number" is really just a string of the form: -
major-minor-release
+
major-minor-release
A change in the major version number indicates a fundamental change in the architecture of the system, e.g. OpenACS 3 to ACS 4. A change in the minor version number signifies the addition of @@ -72,12 +72,12 @@
In the future, OpenACS packages should follow this same convention on version numbers. -
So what distinguishes an alpha release from a beta +
So what distinguishes an alpha release from a beta release? Or from a production release? We follow a specific set of rules for how OpenACS makes the transition from one state of maturity to the next.
Every release must pass the minimum requirements that it cleanly installs and cleanly upgrades from the previous version of OpenACS. In -addition to this the release label implies:
- development +addition to this the release label implies:
- development
This is the default state for the head of the current release branch. We make no guarantees about this code.
- alpha
All tickets of severity critical have been closed and the @@ -86,9 +86,9 @@ and all documentation is up to date (version history, release notes, new module docs, etc.).
- production [0, 1, ...]
All tickets of severity medium or greater have been closed, -including issues reported from outside users.
In the future we will guarantee that more mature releases +including issues reported from outside users.
In the future we will guarantee that more mature releases incorporate all the fixes for earlier problems by developing a detailed set of regression tests. For now we try to enforce this by restricting work on the release branch to fixing reported problem in the current release, e.g. no new features or big changes to -fundamental behavior.
($Id$)