CASA Version Numbering
The goal of CASA version numbering is to provide a simple description of periodic CASA builds which has a direct correlation to a particular source code revision. It is important that this correspondence be maintained as development progresses so that users and developers can be confident that they are referring to the same thing when discussing problems or features.
CASA Versions (New convention)
The various build and packaging changes detailed below are intended to provide CASA developers, user testers and end-users with a simpler, more self-consistent convention for identifying packages. Behind the scenes, the new system should obviate the need for the large merges between development branches that have previously hindered timely public CASA releases.
In addition to the changes below, the reader is also advised to review the (comparatively minor) changes to the new CASA launch commands that are described in detail here
Package Types ("test", "stable", etc.)
In terms of what package types will be automatically available at the NRAO (via RPM, Tarball or .dmg), the following versions will be supported:
- Test: In order to support staff who need fast access to the latest capabilities we are increasing the frequency of the "test" package. "Test" will be used to denote any nightly package that has build successfully and is known to start. No additional testing constraints are being placed on these packages, and so users may consequently find them to be less robust.
- Stable: Any such "test" package (as defined above) that is found to pass all of the regression testing will be promoted to be the newest "Stable" package. Note that this means that any such stable will still have passed the same level as testing as the old-style stable packages did. Note that this does mean that the "Stable" package may update fairly frequently: potentially from one night to the next. A longer-term future goal will be to improve the level of automated testing at this stage, which would in turn increase the overall stringency of which "Test" packages qualify for promotion to "Stable" status.
- Monthly: On the first day of each month, the latest "stable" package will be labelled as the new "monthly" package. This new "monthly" will remain unchanged for the remainder of the month. This tier is intended to balance the need for rapid updates of the code with requirements of stability for long running jobs.
- Release: These will be the semi-annual releases. These packages will have been subjected to additional human user testing beyond the automated testing. These will be accompanied by the usual accompanying documentation updates. Release packages will come from a "Release" branch that is triggered following the production of a suitable "Stable" package that has been identified to be "feature complete" for the purposes of the upcoming public release.
Human user testing should consequently be conducted on "Stable", "Monthly" or "Release" packages. This should minimize user tester exposure to packages that have not passed automated testing first.
A more self-consistent method of version identification is being adopted. A summary is provided in this section.
In future, all CASA packages will be identified by a number of the format X.Y.Z-TYPE (e.g. "4.5.6-DEV"). This is reported when CASA is launched, and the X.Y.Z number is also reflected in the filename of the corresponding tarball ( see here for details
- X: This is the main CASA version number. An increase of X is rare. It denotes some major change to the package as a whole, and the decision to increment X is as much a "marketing" consideration as anything else.
- Y: An increase in this normally denotes the release of a semi-annual CASA public release (unless X has just been incremented, in which case it will be reset to "0").
- Z: This normally denotes the number of the internal-use test (or release branch) package.
- TYPE: "DEV" or "REL" - denotes whether the package is a development build on the trunk (DEV) or a release branch package (REL). Note that this descriptor is not explicitly included in the package filename as it would be redundant (e.g. "casa-release-4.3.0-REL.tar.gz").
The following figure presents an example of a project-centric view of how the various versions will be numbered during the late stages of the CASA 4.4 release cycle. Development versions are initially numbered 4.4.Z-DEV on the code development trunk. Once the 4.4 release branch has been produced (from the 4.4.98-DEV package), the X.Y = 4.4 numbering is only retained for that release branch (the first entry of which is identified as 4.4.0-REL). Packages on this release branch may still receive additional bug fixes, but no new features. Since subsequent trunk packages potentially contain code commits containing new 4.5 features, these are then identified as 4.5.Z development versions, since the new features target the future 4.5.Z-REL release branch.
When a package is publicly released, its initial release will simply be designated as CASA X.Y.0-REL (e.g. CASA 4.4.0-REL). Should there be a need to release a patch to this public release, then the first version containing the patch will be identified as "CASA X.Y.1-REL", etc. This means that the first patch following the CASA 4.4.0-REL release would be called CASA 4.4.1-REL, the second patched version would be 4.4.2-REL, and so on.
Additional Information Useful for Site Deployment
In summary, the following changes are probably the largest causes of practical concern for CASA administration at a tarball-based site:
- The names of the tar files have changed
- The version numbering has changed
- The frequency of the updates has changed
- A "Monthly" package will be added
- "Test" packages may be less trustworthy
- Tar files are now built for both RHEL5 and RHEL6 ("RHEL" = Red Hat Enterprise Linux)
The following section attempts to directly address these possible causes for concern.
RHEL5 and RHEL6
The newly-produced Linux "test" tarball packages (and their associated MD5 checksums) are retrievable from the following locations:
The newly-produced Linux "stable" tarball packages are retrievable from the following locations:
The newly-produced Linux "monthly" tarball packages are retrievable from the following locations:
The newly-produced Linux "prerelease" tarball packages are retrievable from the following locations:
The newly-produced Linux "release" tarball packages are retrievable from the following locations:
Note that the URLs for these are the same as those used previously, except for the addition of "el5" and "el6" subdirectories. This is because the new system also builds and tests RHEL6-native packages, in addition to the RHEL5 packages previously produced. These RHEL6-native packages may be preferred by RHEL6 users.
Corresponding directories following the same naming conventions will be added as native packages for RHEL7, RHEL8, etc. are added to the routine build and packaging process in the future.
Mac OS X
The newly-produced OS X .dmg "test" packages will be retrievable from the following locations:
The newly-produced OS X .dmg "stable" packages will be retrievable from the following locations:
The newly-produced OS X .dmg "monthly" packages will be retrievable from the following locations:
The newly-produced OS X .dmg "prerelease" tarball packages are retrievable from the following locations:
The newly-produced OS X .dmg "release" tarball packages are retrievable from the following locations:
Corresponding directories following the same naming conventions will be added as native packages for OS X 10.9, 10.10, etc. are added to the routine build and packaging process in the future.
Although details are still being finalized, the future structure will eventually be something like:
The naming convention for the tarball packages is as follows:
The downloadable tarball packages will be named in a manner that clearly denotes whether a package is a "test", "stable", "monthly" or "release" package, along with the specific X.Y.Z version number described above.
An example of a new-style filename is as follows:
This example denotes that this is a gzipped, tarball containing a CASA "Stable" package. This particular "Stable" package was derived from "Test" package number 21 of the 4.2 development cycle.
For the immediate future, each tarball entry will also be listed in a publicly accessible look-up table with the Subversion revision number associated with the build. This will enable user testers to rapidly check the availability of a given code revision in a given package.
Any user that needs to check if a specific Subversion revision number is included in a given package should consult the look-up table here.
will contain links to the latest stable, monthly, and releases. Users will be able to just link to this in order to have access to the correct CASA versions. They will be able to add their own versions as well (e.g. private builds, etc.).
For user installations, the following logic should be used to establish the default versions of CASA that will be available to users:
- If the directory
~/.casa/versions/ exists for the user, it is searched for unpacked versions of CASA.
- CASA versions linked in
~/.casa/versions/ are preferentially selected over system versions of the same version number.
- Released versions take precedence over unreleased versions.
- The directory
/home/casa/versions/ will be provided as an easy way for users to create a symlink to the site-wide archive.
- The only RPM versions that will be installed are casa (release), "test", "stable", and "monthly". Other versions will be accessible via a version archive.
The above approach provides access to the latest published packages by default. The public release version is launched by default with the "casa" command. However, the above framework still allows users to access custom or archival versions.
The RHEL5 and RHEL6 systems should have a casa.repo file for yum:
bash$ cat /etc/yum.repos.d/casa.repo
name=CASA RPMs for RedHat Enterprise Linux 5 (x86_64)
gpgkey=http://svn.cv.nrao.edu/casa/RPM-GPG-KEY-casa http://www.jpackage.org/jpackage.asc http://svn.cv.nrao.edu/casa/repo/el5/RPM-GPG-KEY-redhat-release http://svn.cv.nrao.edu/casa/repo/el5/RPM-GPG-KEY-EPEL
bash$ cat /etc/yum.repos.d/casa.repo
name=CASA RPMs for RedHat Enterprise Linux 6 (x86_64)
gpgkey=http://svn.cv.nrao.edu/casa/RPM-GPG-KEY-casa http://www.jpackage.org/jpackage.asc http://svn.cv.nrao.edu/casa/repo/el6/RPM-GPG-KEY-redhat-release http://svn.cv.nrao.edu/casa/repo/el6/RPM-GPG-KEY-EPEL
yum install casa-test casa-stable-bin
This will install the new wrapper (casapy-test) and the binaries for the test and stable.
All old-style casapy-test, casapy-stable, casapy-launchers RPMs should be removed. (It is possible to make this happen automatically on all hosts when we deploy).
The casapy-stable etc. are the older versions: just remove casapy-stable with "rpm -e casapy-stable". If the "casapy-launchers" RPM is installed, you should remove it too, the base CASA RPM (e.g. one of casa-stable, casa-prerelease, etc.) provides what used to be supplied with the casapy-launchers, so for example a typical system in Charlottesville has the following CASA RPMs installed:
The 'casa430-bin' RPM ensures that the 4.3.0 release will continue to be installed even after 'casa-release-bin' is updated to 4.4.0. In this way the new release will be acquired when it is available, and if (say) casa440-bin is installed (when it is available), the 4.4.0 release will persist regardless of the updates to 'casa-release-bin'.
RPM Collection Summary
In practice, there are five collections:
- casa-test: untested (other than confirming a successful launch); updated daily
- casa-stable: all automated tests are run on the latest casa-test and if it passes it is promoted (without recompile) to be casa-stable
- casa-monthly: at the first of the month, the latest casa-stable is relabeled casa-monthly
- casa-prerelease: created from a release branch and is only made available if all automated tests pass
- casa-release: the final casa-prelease version before a release or a patch is promoted to be casa-release
This means that for periods of time there will be overlap in terms of the physical files installed, e.g. casa-monthly and casa-stable will share the same files on disk until a new casa-stable is created.
The leading RPM for each variety (e.g. casa-test-4.4.8-1.el6.x86_64.rpm or casa-prerelease-4.3.0-2.el6.x86_64.rpm) includes (only) the former wrapper script. The 'bin' RPMs (e.g. casa-test-bin-4.4.8-1.el6.x86_64.rpm or casa-prerelease-bin-4.3.0-2.el6.x86_64.rpm) install the actual CASA distribution. The wrapper script then makes all of the RPM distributions available. So this means that in order to install all of the currently available varieties of CASA, the following should be run:
yum install casa-test casa-stable-bin casa-prerelease-bin
Installing casa-test instead of casa-release (for example) ensures that updates to the wrapper script will arrive in a timely fashion, i.e. every day instead of every 6 months when CASA releases appear. Eventually, there will also be casa-monthly-bin and casa-release-bin to install.
Additional AOC Deployment Information
The Linux tar files have been deployed in /home/casa/packages and the launchers updated. The latest prerelease package can be started with casapy-prerelease
- The casa -ls feature is RPM specific. If a using casa installations in /home/casa/packages, theyll have to navigate the folder tree to see all versions available to them.
- To run a version of casa other than the version currently invoked by casapy-test, casapy-stable, casapy-prerelease, etc., a user can start a specific version by running in a subshell or prepending to their PATH. For example, to start casa-test-4.4.1:
§ # (exec /home/casa/packages/RHEL5/test/casa-test-4.4.1/casa)
§ # PATH=/home/casa/packages/RHEL5/test/casa-test-4.4.1:$PATH
§ # casa
The below is old draft text, and should now be regarded as deprecated
Description and Example
CASA will use three version numbers to denote builds for future versions,
. Each of these triplets will generally correspond to a particular version control revision.
will be incremented as part of public releases which are coordinated by CASA management and implemented by CASA developers.
will be used to denote test builds which are untested and currently in the process of automated testing. Some subset of these test builds will pass all applicable testing and these versions will be renamed to indicate that they are
. Here's an example of a portion of a development cycle:
revision trunk branch release branch
-------- -------------------------------------- -------------------------
52809 casa-test-5.0.1 <-- fail
53811 casa-test-5.0.2 <-- fail
53816 casa-test-5.0.3 casa-stable-5.0.3 <-- pass
53818 casa-test-5.0.4 <-- fail
53823 casa-test-5.0.5 <-- fail
53825 casa-test-5.0.6 casa-stable-5.0.6 <-- pass
53828 casa-test-5.0.7 casa-stable-5.0.7 <-- pass
53832 casa-test-5.0.8 casa-stable-5.0.8 <-- pass
53834 casa-test-5.0.9 <-- fail
53837 casa-6.0.0 (branched from 53832)
53839 casa-test-6.0.1 <-- fail
*53843 casa-6.0.0-01 <-- fail
53844 casa-test-6.0.2 <-- fail
53847 casa-test-6.0.3 casa-stable-6.0.3 <-- pass
53849 casa-6.0.0-02 <-- fail
*53852 casa-6.0.0-03 (deliver to users) <-- pass
53855 casa-test-6.0.4 casa-stable-6.0.4 <-- pass
In this example,
indicates revisions which were made to a release branch. The tags along the right side indicate which releases have passed all tests (and which failed). With each new development build, the
number is incremented. For releases, a particular trunk build which passes all required automated tests and contains all necessary features is selected and a branch is created. The release is prepared and finally released; all the while the version number that the user sees is unchanged. The next
release will result in another (preferably stubby) branch being created to prepare for the release. Only small patches issued shortly after a release would be drawn from a given release branch.
The current test version is available from:
It provides both the version number and the source revision that should be used for building versions of CASA that are to be used for internal testing. This release number will be updated no more often than once per day. In the event that no changes are made since the previous increment, the version number will remain unchanged. The full version number series is available from:
The expectation is that this will only be used for reference purposes, but of course, it could be used to rebuild an old version from scratch.
version numbers are incremented at time which the project deems appropriate. Perhaps for releases or for patch versions. These numbers are changed from:
Once one of these numbers is incremented, then
is reset to
. A release branch will be created from the last
that has passed all automated tests, and builds on this new branch will be numbered
until the release is ready to be pushed out to users.