Index: openacs-4/packages/acs-core-docs/www/xml/engineering-standards/eng-standards-versioning.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/engineering-standards/eng-standards-versioning.xml,v
diff -u -N -r1.4.2.1 -r1.4.2.2
--- openacs-4/packages/acs-core-docs/www/xml/engineering-standards/eng-standards-versioning.xml 17 Nov 2003 16:38:09 -0000 1.4.2.1
+++ openacs-4/packages/acs-core-docs/www/xml/engineering-standards/eng-standards-versioning.xml 2 Feb 2004 18:07:48 -0000 1.4.2.2
@@ -9,6 +9,7 @@
By Ron Henderson
+Revised by Joel Aufrecht
@@ -18,55 +19,62 @@
-major-minor-release
+major.minor.dot[ milestone ]
-
-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:
-
-
+
+
+ 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
-
-alpha
-beta
-0 (production release)
-1
-2
-...
-
-
-So typical release version numbers would be:
-
-
-
-
-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:
+(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
@@ -114,60 +122,11 @@
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.
+the next. These rules are fine-tuned with each release; an example is 5.0.0 Milestones and Milestone Criteria
- 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
-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$)
+