CASA Version Numbering

Objective

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.

Version Identification

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

Overview

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.

Package locations

RHEL5 and RHEL6

The newly-produced Linux "test" tarball packages (and their associated MD5 checksums) are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/linux_distro/test/el5/ - RHEL5
• https://svn.cv.nrao.edu/casa/linux_distro/test/el6/ - RHEL6

The newly-produced Linux "stable" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/linux_distro/stable/el5/ - RHEL5
• https://svn.cv.nrao.edu/casa/linux_distro/stable/el6/ - RHEL6

The newly-produced Linux "monthly" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/linux_distro/monthly/el5/
• https://svn.cv.nrao.edu/casa/linux_distro/monthly/el6/

The newly-produced Linux "prerelease" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/linux_distro/prerelease/el5/
• https://svn.cv.nrao.edu/casa/linux_distro/prerelease/el6/

The newly-produced Linux "release" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/linux_distro/release/el5/
• https://svn.cv.nrao.edu/casa/linux_distro/release/el6/

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:

• https://svn.cv.nrao.edu/casa/osx_distro/test/10.8/ - OS X 10.8

The newly-produced OS X .dmg "stable" packages will be retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/osx_distro/stable/10.8/ - OS X 10.8

The newly-produced OS X .dmg "monthly" packages will be retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/osx_distro/monthly/10.8/ - OS X 10.8

The newly-produced OS X .dmg "prerelease" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/osx_distro/prerelease/10.8/

The newly-produced OS X .dmg "release" tarball packages are retrievable from the following locations:

• https://svn.cv.nrao.edu/casa/osx_distro/release/10.8/

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.

The future

Although details are still being finalized, the future structure will eventually be something like:

• casa/versions/4.3/test/el5
• casa/versions/4.3/test/el6
• casa/versions/4.3/test/osx10.8
• casa/versions/4.3/test/osx10.8
• casa/versions/4.3/release/el5
• casa/versions/4.3/release/osx10.8

Filenames

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:

casa-stable-4.2.21.tar.gz

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.

User Paths

The directory

/home/casa/versions

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:

1. If the directory

   ~/.casa/versions/

   exists for the user, it is searched for unpacked versions of CASA.
2. CASA versions linked in

   ~/.casa/versions/

   are preferentially selected over system versions of the same version number.
3. Released versions take precedence over unreleased versions.
4. The directory

   /home/casa/versions/

   will be provided as an easy way for users to create a symlink to the site-wide archive.
5. 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.

RPM installations

The RHEL5 and RHEL6 systems should have a casa.repo file for yum:

RHEL5

bash$ cat /etc/yum.repos.d/casa.repo 
[casa]
name=CASA RPMs for RedHat Enterprise Linux 5 (x86_64)
baseurl=http://svn.cv.nrao.edu/casa/repo/el5/x86_64
gpgcheck=0
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$

RHEL6

bash$ cat /etc/yum.repos.d/casa.repo 
[casa]
name=CASA RPMs for RedHat Enterprise Linux 6 (x86_64)
baseurl=http://svn.cv.nrao.edu/casa/repo/el6/x86_64
gpgcheck=0
enable=1
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
bash$  

Then run:

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:

casa-stable
casa-release-bin
casa-monthly-bin
casa430-bin

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
casa-stable
casa-monthly
casa-prerelease
casa-release

Their attributes:

• 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, they’ll 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:
  • Run in subshell:

§  # (exec /home/casa/packages/RHEL5/test/casa-test-4.4.1/casa)

• • Prepend to PATH:

§  # 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, <MAJOR>.<MINOR>.<TEST>. Each of these triplets will generally correspond to a particular version control revision. <MAJOR>.<MINOR> will be incremented as part of public releases which are coordinated by CASA management and implemented by CASA developers. <TEST> 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 stable. Here's an example of a portion of a development cycle:

 revision  trunk branch                              release branch
 --------  --------------------------------------    -------------------------
 52809     casa-test-5.0.1                                                                 <-- fail
 52810
 53811     casa-test-5.0.2                                                                 <-- fail
 53812
 53813
 53814
 53815
 53816     casa-test-5.0.3    casa-stable-5.0.3                                            <-- pass
 53817
 53818     casa-test-5.0.4                                                                 <-- fail
 53819
 53820
 53821
 53822
 53823     casa-test-5.0.5                                                                 <-- fail
 53824
 53825     casa-test-5.0.6    casa-stable-5.0.6                                            <-- pass
 53826
 53827
 53828     casa-test-5.0.7    casa-stable-5.0.7                                            <-- pass
 53829
 53830
 53831
 53832     casa-test-5.0.8    casa-stable-5.0.8                                            <-- pass
 53833
 53834     casa-test-5.0.9                                                                 <-- fail
 53835
 53836
 53837                                               casa-6.0.0 (branched from 53832)
 53838
 53839     casa-test-6.0.1                                                                 <-- fail
 53840
 53841
*53842
*53843                                               casa-6.0.0-01                         <-- fail
 53844     casa-test-6.0.2                                                                 <-- fail
 53845
*53846
 53847     casa-test-6.0.3    casa-stable-6.0.3                                            <-- pass
 53848
 53849                                               casa-6.0.0-02                         <-- fail
*53850
*53851
*53852                                               casa-6.0.0-03 (deliver to users)      <-- pass
*53853
*53854
 53855     casa-test-6.0.4    casa-stable-6.0.4                                            <-- pass
 53856

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 <TEST> 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 <MINOR> or <MAJOR> 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.

Operational Details

The current test version is available from:

• https://svn.cv.nrao.edu/cgi-bin/casa-version

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:

• https://svn.cv.nrao.edu/cgi-bin/casa-version-series

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.

The <MAJOR> and <MINOR> version numbers are incremented at time which the project deems appropriate. Perhaps for releases or for patch versions. These numbers are changed from:

• https://svn.cv.nrao.edu/svn/casa/version/

Once one of these numbers is incremented, then <TEST> is reset to 1. A release branch will be created from the last <TEST> that has passed all automated tests, and builds on this new branch will be numbered <MAJOR>.<MINOR>.0 until the release is ready to be pushed out to users.

---

-- DarrellSchiebel - 2014-10-02