| Prev | Chapter 9. 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.dot[ milestone ]
A major number change indicates a fundamental change in the architecture of the system, e.g. OpenACS 3 to ACS 4. A major change is required if core backwards compatibility is broken, if upgrade is non-trivial, or if the platform changes substantially.
A minor change represents the addition of new functionality or changed UI.
A dot holds only bug fixes and security patches. Dot releases are always recommended and safe.
A milestone marker indicates the state of the release:
d, for development, means the release is in active development and is not in its intended released form.
a, for alpha, means new development is complete and code checkins are frozen. Alpha builds should work well enough to be testable.
b, for beta, means most severe bugs are fixed and end users can start trying the release.
Release Candidate builds (rc) are believed to meet all of the criteria for release and can be installed on test instances of production systems.
Final releases have no milestone marker. (Exception: In CVS, they are tagged with -final to differentiate them from branch tags.)
Milestone markers are numbered: d1, d2, ..., a1, b1, rc1, etc.
A complete sequence of milestones between two releases:
5.0.0 5.0.0rc2 5.0.0rc1 5.0.0b4 5.0.0b1 5.0.0a4 5.0.0a3 5.0.0a1 5.0.0d1 4.6.3
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 '-'.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 head: 3.1 branch: locks: strict access list: symbolic names: acs-4-0: 3.1.0.8 acs-3-2-2-R20000412: 3.1 acs-3-2-1-R20000327: 3.1 acs-3-2-0-R20000317: 3.1 acs-3-2-beta: 3.1 acs-3-2: 3.1.0.4 acs-3-1-5-R20000304: 1.7.2.2 acs-3-1-4-R20000228: 1.7.2.2 acs-3-1-3-R20000220: 1.7.2.2 acs-3-1-2-R20000213: 1.7.2.1 acs-3-1-1-R20000205: 1.7.2.1 acs-3-1-0-R20000204: 1.7 acs-3-1-beta: 1.7 acs-3-1-alpha: 1.7 acs-3-1: 1.7.0.2 v24: 1.5 v23: 1.4 start: 1.1.1.1 arsdigita: 1.1.1 keyword substitution: kv total revisions: 13; selected revisions: 13 description: ...
In the future, OpenACS packages should follow this same convention on version numbers.
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. These rules are fine-tuned with each release; an example is 5.0.0 Milestones and Milestone Criteria