6. Release Version Numbering

Table of Contents

6.1. Transition Rules

-ACS version numbers help identify at a high-level what is in a + + + + +Release Version Numbering + + + + + + + + +

+ + + +

+Prev�	Chapter 6. Engineering Standards	�Next +

+Release Version Numbering

By Ron Henderson +

+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

-A change in the major version number indicates a fundamental -change in the architecture of the system, e.g. ACS 2 to ACS 3. A -change in the minor version number signifies the addition of -new modules and minor data model changes, e.g. ACS 3.1 to ACS 3.2. -The final release number indicates the relative maturity of a +"version number" is really just a string of the form: +

+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 +new modules and minor data model changes, e.g. OpenACS 3.1 to OpenACS 3.2. +The final release number indicates the relative maturity of a release and marks things like bug fixes; it follows the ordered progression: -

+
+ alpha
 beta
 0 (production release)
 1
 2
 ...
-

+ +

So typical release version numbers would be: -

-acs-3.2.2
-acs-4.0.beta
-

-The first is a relatively mature release of the ACS 3.2 base code -and the second is a non-public release of ACS 4.0 that probably still +

+openacs-3.2.5
+openacs-4.0.beta
+

+The first is a relatively mature release of the OpenACS 3.2 base code +and the second is a non-public release of OpenACS 4.0 that probably still has lots of bugs. -

Version numbers are also recorded in the CVS repository so that the code tree can be restored to the exact state it was in for a particular release. To translate between a distribution tar file (acs-3.2.2.tar.gz) and a CVS tag, just swap '.' for '-' and add the release date. The entire release history of the toolkit is recorded in the tags for the top-level readme.txt file: -

+
+ > cvs log readme.txt
 RCS file: /usr/local/cvsroot/acs/readme.txt,v
 Working file: readme.txt
@@ -66,26 +103,72 @@
 total revisions: 13;	selected revisions: 13
 description:
 ...
-

-In the future, ArsDigita packages should follow this same + +

+In the future, OpenACS packages should follow this same convention on version numbers. -

6.1. Transition Rules

So what distinguishes an alpha release from a beta +

+Transition Rules

So what distinguishes an alpha release from a beta release? Or from a production release? We follow a specific set of -rules for how ACS 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 ACS. In -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 -distribution has no known installation or upgrade problems.
beta -
All tickets of severity serious or greater have been closed +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 +
+
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 +distribution has no known installation or upgrade problems.
+
beta +
+
All tickets of severity serious or greater have been closed 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 +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 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$)

acs-docs@arsdigita.com

+fundamental behavior.

($Id$)

+Prev�	Home	�Next +
System/Application Requirements Template�	Up	�Constraint naming standard