CASA Requirement: Version Identification
Some CASA users, developers, and management have expressed frustration with the current CASA version identification scheme as confusing and verbose.
This page describes a new CASA version identification scheme to concisely and uniquely identify
- a CASA package,
- the source code used to build that package,
- the contents of that package as a release, stable, or test package,
- the place in a sequence of packages including packaging fixes, and
- indicate progress developing new features for the next CASA releases.
- This scheme applies to complete, integrated, and tested CASA packages.
- This scheme does not apply to builds used to determine if CASA is ready for packaging.
- To be discussed with CASA Developers.
- CASA shall display version identifiers at run time on the CASA console and in CASA logs.
- CASA packages shall include version identifiers in package names, within restrictions enforced by Linux and OS X package managers.
- Unpacked CASA generic Linux tar and OS X packages shall include version identifiers in directory names that these packages unpack to.
- CASA version identifiers must allow us to produce valid package names for all Linux distributions and OS X versions CASA is required to support.
- CASA version identifiers must allow us to map from the version identifier to the exact source code used to build the package.
CASA will use a 3 place sequence number X.Y.Z to identify the source code used to build the package, and to indicate if the package has passed sufficient testing to be used as a test, stable, or release package.
- Released packages
- Are identified with version numbers X.0.0,
- have passed User Acceptance Testing.
- Bug Fixes to released packages
- are identified with version numbers X.0.Z, Z/=0.
- Z will start at 1 and increment by 1 for each bug fix to a release package.
- Stable packages
- are identified with version numbers X.Y.0, Y /= 0,
- Y will start at 1 and increment by 1 for each stable package.
- include new development since X.0.0 and progress towards X+1.0.0,
- have not yet passed User Acceptance Testing,
- will not change for at least several weeks, and
- have been tested more thoroughly than a test package.
- Test packages
- are identified with version numbers X.Y.Z, Z /= 0,
- Z will start at 1 and increment by 1 for each test package.
- include new development since X.Y.0, and progress towards X.Y+1.0,
- have not yet passed User Acceptance Testing, and
- will be superseded in about one week.
CASA will also use a sequence number P to identify a packaged build. P starts at 1 for any X.Y.Z, and increments for each repackaging of the same source code build to fix an issue in a previously published package (missing files, incorrect permissions, etc.). A series of package fixes would be numbered:
etc.. The only differences between these packages would be in packaging, not in the version of CASA source code the packages are built from.
CASA will use Subversion tags with the same version number as the package to identify the CASA source code used to build a package.
CASA will no longer use the labels "test", "stable", "prerelease, "release". This numbering scheme makes these labels redundant.
CASA release packages can either remain tied to the calendar (one every six months) or the development cycle, or (recommended) be updated when a major feature or set of features is complete and has passed User Acceptance Testing. This is a management decision.
CASA stable packages can either remain tied to the calendar (one a month), or (recommended) be updated when a minor feature or set of features is complete and available for User Acceptance Testing, but has not yet passed User Acceptance Testing. This is a management decision.
CASA test packages will remain tied to the calendar (one a week) for now.
We are wrapping up the CASA 4.2.0 release. I am preparing the first test package for the next CASA release. This will be identified as version "4.3.0 test r28570" under the old scheme. Under the new scheme this would be identified as version "4.3.1". Following test packages would be identified as version "4.3.2", "4.3.3", etc., until we have completed enough features and fixed enough bugs to create a stable package. That stable package would be identified as version "4.4.0". These and following packages would appear in the sequence:
- casa-4.3.1-1 - first test package of current development cycle.
- casa-4.3.2-1 - second test package of current development cycle.
- casa-4.4.0-1 - first stable package of current development cycle.
- casa-4.4.0-2 - repackage of casa-4.4.0-1 to correct packaging issue.
- casa-4.4.1-1 - first test package adding new code to casa-4.4.0 stable.
- casa-4.4.2-1 - second test package adding new code to casa-4.4.0 stable.
- casa-4.4.3-1 - etc.
Assuming we continue the practice of deferring the bulk of User Acceptance Testing until after the features planned for a development cycle are "done".
- casa-4.5.0-1 - Assuming the next feature freeze is in May, this last stable package of a development cycle. Features are now frozen for User Acceptance Testing.
- casa-4.5.1-1 - First bugfix package for issues found in User Acceptance Testing.
- casa-4.5.2-1 - Second bugfix package for issues found in User Acceptance Testing.
- casa-4.5.3-1 - Third bugfix package for issues found in User Acceptance Testing.
- casa-5.0.0-1 - The "release" package, after passing User Acceptance Testing.
- casa-5.1.1-1 - The first test package following the release.
- Note: Incrementing both stable and test numbers for the first test package distinguishes test packages from release bug fixes.
- casa-5.1.2-1 - The second test package following the release.
After some progress towards the next "release".
- casa-5.3.2-1 - A test package
- casa-5.0.1-1 - The first bug fix to the latest "release" package.
- casa-5.3.3-1 - Back to development for the next "release".
This scheme is the product if a long email discussion (not capture outside of personal mail archives), and a series of proposals
on the wiki. We are saving the series of proposals to document alternatives considered before arriving at this scheme.