CASA Requirement: Version Identification - Discussion

This page describes the version identification scheme used by CASA to uniquely identify

  • a set of CASA features,
  • CASA source code used to create a build, and
  • a CASA build,
  • a CASA package.

This version identification scheme will also help developers and users understand where a CASA build or package was created during development of a set of CASA features.

Note: Schemes described on this page apply to a complete, integrated, and tested CASA package. They do not yet apply to any CASA components we may be required to distribute independently.

STATUS:
  • Proposals 3 and 1A submitted to CASA Management.
  • New: Proposals 4 and 5.

Required Use

  • 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 used on OSs CASA is required to support.
  • Unpacked CASA generic Linux and OS X dmg packages shall include version identifiers in directory names that these packages unpack to.

Constraints

  • CASA version identifiers must allow us to produce valid package names for all of the 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 create the package.

Proposal 1

Mostly by Jeff Kern. Some tweaks by Scott Rankin.

Numbering Scheme

CASA will use a 4 place sequence number (W.X.Y.Z) to identify software packages.

  1. The first place (W), identifies the CASA major release.
  2. The second place (X), identifies the CASA minor release.
  3. The third place (Y), identifies stable packages within a development cycle, or a pre-release or a release package at the end of a development cycle.
  4. The fourth place (Z), identifies test packages within a development cycle, or a bug fix to a pre-release or release package at the end of a development cycle.

The first and second places identify a CASA release as a set of features. All four places together identify a package, and it's location is a sequences of packages in a development cycle leading up to a release.

Incrementing Numbers

  1. The first place will increment at the start of a CASA development cycle when management decides there are enough changes planned for a release to call it a major release.
    • At that time, the second, third, and fourth places reset to 0.
  2. The second place increments at the start of every CASA development cycle that does not meet the criteria for a major release.
    • At that time, the third, and fourth places reset to 0.
  3. The third place increments before a stable package is published, before the first pre-release package for a development cycle is published, and before the release package for a development cycle is published.
    • At this time, the fourth place resets to 0.
  4. The fourth place increments before a CASA test package is published, before a publishing a bug fix pre-release package, and before publishing a bug fix to a released package.

An Example

Management has decided the features planned for the next CASA release do not constitute a major release. The set of features included in the next CASA development cycle will be named CASA 4.2.

The first package of the CASA 4.2 development cycle will be a test package. This will be numbered 4.2.0.1, indicating the first test package of the CASA 4.2 development cycle. Following test packages will be numbered 4.2.0.2, 4.2.0.3, etc., until we publish a stable package.

The first stable package for the CASA 4.2 development cycle is due after April 15. This will be numbered 4.2.1.0, indicating it is the first stable package of the CASA 4.2 development cycle. Following test packages will be numbered 4.2.1.1, 4.2.1.2, 4.2.1.3, etc., indicating they build on the preceding stable package.

The second stable package for the CASA 4.2 development cycle is due after May 15. This will be numbered 4.2.2.0, indicating it is the second stable package of the CASA 4.2 development cycle. Following test packages will be numbered 4.2.2.1, 4.2.2.2, 4.2.2.3, etc., indicating they build on the preceding stable package.

Assuming the CASA 4.2 feature freeze occurs on schedule (September 15), the last stable package for the CASA 4.2 development cycle will be numbered 4.2.6.0.

The first pre-release package for the CASA 4.2 development cycle is due after the last stable package is published. It will be numbered 4.2.7.0. Following pre-release packages for CASA 4.2 will be labeled 4.2.7.1, 4.2.7.2, etc.. This will continue until the pre-release packages are good enough to release.

The final release package for the CASA 4.2 development cycle will be labeled with a number 4.2.8.0

Patch releases to this release, if any, will be identified by incrementing the version by 4.2.8.1, 4.2.8.2, etc..

Alternately, from this example

  • 4.2 - Release version
    • 4.2.0.1 - first test package of 4.2 development cycle
    • 4.2.0.2 - second test package
    • 4.2.0.3 - next test package
...
  • 4.2.1.0 - first stable package of 4.2 development cycle
    • 4.2.1.1 - next test package
    • 4.2.1.2 - next test package
    • 4.2.1.3 - next test package
    • 4.2.1.4 - next test package
  • 4.2.2.0 - next stable package
    • 4.2.2.1 - next test package
    • 4.2.2.2 - next test package
    • 4.2.2.3 - next test package
...
  • 4.2.6.0 - last stable package of 4.2 development cycle
  • 4.2.7.0 - first pre-release package of 4.2 development cycle
    • 4.2.7.1 - second pre-release package - bug fixes to first pre-release package
    • 4.2.7.2 - third pre-release package - bug fixes to second pre-release package
    • 4.2.7.3 - fourth pre-release package - bug fixes to third pre-release package - good enough to release
  • 4.2.8.0 - final CASA 4.2 release package
    • 4.2.8.1 - first bug fix to CASA 4.2 release

The example above assumes the CASA 4.2 feature freeze occurs on schedule. If the feature freeze occurs one month later, pre-release and release package version numbers will increase.

...
  • 4.2.7.0 - last stable package of 4.2 development cycle
  • 4.2.8.0 - first pre-release package of 4.2 development cycle
    • 4.2.8.1 - second pre-release package - bug fixes to first pre-release package
    • 4.2.8.2 - third pre-release package - bug fixes to second pre-release package
    • 4.2.8.3 - fourth pre-release package - bug fixes to third pre-release package - good enough to release
  • 4.2.9.0 - final CASA 4.2 release package
    • 4.2.9.1 - first bug fix to CASA 4.2 release

-- ScottRankin - 2013-03-25

Proposal 1A

Jeff Kern, after discussion with Scott Rankin.

Numbering Scheme

CASA will use a 4 place sequence number, plus a package number (W.X.Y.Z-P) to identify software packages, and to show progress from one release to the next release.

  1. The first place (W), identifies the CASA major release.
  2. The second place (X), identifies the CASA minor release.
  3. The third place (Y), identifies stable packages within a development cycle, or a pre-release a release package at the end of a development cycle.
  4. The fourth place (Z), identifies test packages within a development cycle, or a sequence of pre-release packages at the end of a development cycle.
  5. The last place (P), identifies a package in a sequence of W.X.Y.Z package builds. A number greater than 1 indicates a fix to an already published package.

These numbers together identify the CASA release that the package builds on, and progress towards the next release. When CASA is ready to release, management will assign a new W.X value, Y and Z will be 0, and P will be 1.

The first release packages for each release will have numbers like:

  • 4.3.0.0-1
  • 4.4.0.0-1
  • 5.0.0.0-1

CASA will NOT use a test quality (test | stable | prerelease | release) label in package identifiers. This is encoded in the Y and Z digits of the version ID.

Incrementing Numbers

Development starts in a new development cycle building on the first release of the previous development cycle. For example CASA 4.2.0.0-1.

  1. We increment Y when we publish a stable package or a pre-release package at the end of the development cycle.
    • When we increment Y, we set Z to 0.
  2. We increment Z when we publish a test package between stable packages, and when we update pre-release packages before the final release.
  3. We increment P when we must fix a problem found in a published package.

  1. At release time,
    • If management decides there are enough changes to call this release a major release, we increment W, and set X, Y and Z to 0, and P to 1.
    • If management decides there are not enough changes to call this release a major release, we preserve W, increment X, and set Y and Z to 0, and P to 1

An Example

We have just released CASA 4.2.0.

The first package of the new development cycle will be a test package. This will be numbered 4.2.0.1-1, indicating the first test package that builds on the CASA 4.2.0.0 release. Following test packages will be numbered 4.2.0.2-1, 4.2.0.3-1, etc., until we publish a stable package.

The first stable package of the new development cycle is due after April 15. This will be numbered 4.2.1.0-1, indicating it is the first stable package that builds on the CASA 4.2.0.0 release. If we must publish a bug fixes to this package, they will be numbered 4.2.1.0-2, 4.2.1.0-3, etc. Following test packages will be numbered 4.2.1.1-1, 4.2.1.2-1, 4.2.1.3-1, etc., indicating they build on this stable package.

The second stable package of the new development cycle is due after May 15. This will be numbered 4.2.2.0-1, indicating it is the second stable package that builds on the CASA 4.2.0.0 release. Following test packages will be numbered 4.2.2.1-1, 4.2.2.2-1, 4.2.2.3-1, etc., indicating they build on this stable package.

Assuming the new development cycle feature freeze occurs on schedule (September 15), the last stable package for the new development cycle will be numbered 4.2.6.0-1.

The first pre-release package for the new development cycle is due after the last stable package is published. It will be numbered 4.2.7.0-1. Following pre-release packages for the new development cycle will be labeled 4.2.7.1-1, 4.2.7.2-1, etc.. This will continue until the pre-release packages are good enough to release.

When CASA is feature complete, tested, and ready for release, (assuming management decides this release will be named CASA 4.3), we number the first package for that release 4.3.0.0-1

Bug fixes to this release, if any, will be identified by incrementing the package number: 4.3.0.0-2, 4.3.0.0-3, etc..

Alternately, from this example

  • 4.2.0.0-1 - release package for the development cycle with feature freeze on 2013-09
  • 4.2.0.1-1 - first test package of the new development cycle
  • 4.2.0.2-1 - second test package
  • 4.2.0.0-2 - a bug fix for CASA Release 4.2.0.0
  • 4.2.0.3-3 - next test package
...
  • 4.2.1.0-1 - first stable package of 4.2 development cycle
  • 4.2.1.1-1 - next test package
  • 4.2.1.2-1 - next test package
  • 4.2.1.0-2 - a bug fix for the last stable package - required after a bug is found by a user.
  • 4.2.1.3-1 - the test package sequence resumes
  • 4.2.1.4-1 - next test package
  • 4.2.2.0-1 - next stable package
  • 4.2.2.1-1 - next test package
  • 4.2.2.2-1 - next test package
  • 4.2.2.3-1 - next test package
...
  • 4.2.6.0-1 - last stable package of the new development cycle
  • 4.2.7.0-1 - first pre-release package of the new development cycle
  • 4.2.7.1-1 - second pre-release package - bug fixes to first pre-release package
  • 4.2.7.2-1 - third pre-release package - bug fixes to second pre-release package
  • 4.2.7.3-1 - fourth pre-release pacakage - bug fixes to third pre-release package - good enough to release
  • 4.3.0.0-1 - Release package for the new development cycle.
  • 4.3.0.0-2 - first bug fix to CASA 4.3 release

The example above assumes the new development cycle feature freeze occurs on schedule. If the feature freeze occurs one month later, pre-release package version numbers will be different.

-- ScottRankin - 2013-09-16

Proposal 2

Mostly by Scott Rankin.

Identification Scheme

  • CASA will use a 3 place sequence number X.Y.Z to identify a set of features.
    • X.Y, identifies a set of CASA features,
    • Z, a sequence number for bug fix releases. 0 indicates first release of a set of features.

  • CASA will use a sequence number B to identify a build of the set of features described above. B starts at 1 for a given X.Y.Z, and increment for each build that could be published outside the CASA development team for any reason. B will increment frequently during normal CASA development. Not all builds that could be published will be published, so people outside the CASA project will see gaps in the build sequence number.

The numbers X.Y.Z and B uniquely identify both a CASA build, and the source code used to create that build.

  • CASA will use a sequence number P to identify a packaged build. P starts at 1 and increment for each repackaging of the same build. P will increment when it is necessary to repackage a build due to issues in the packaging system. For most packages, P will be 1.

Additionally, packages will be labeled as test, stable, pre-release, and release. This is discussed in CASA Package Naming.

An Example

Management has decided the features planned for the next CASA release do not constitute a major release. The set of features included in the next CASA development cycle will be named CASA 4.3. Since this is the start of development for the 4.3 feature set, X.Y.Z will be 4.3.0.

The first package of the CASA 4.3.0 development cycle will be a test package. The first build will be numbered 4.3.0-1. If this build passes enough tests to be published as a test package, it will be labeled 4.3.0-1-test. If this build is successfully packaged, it will be numbered and labeled 4.3.0-1-test-1. Additional labels will be attached to packages for different Linux distributions and OS X versions as described in CASA Package Naming.

Assuming the next package of the CASA 4.3.0 development cycle will be a stable package. The second build will be numbered 4.3.0-2. If this build passes enough tests to be published as a stable package, it will be labeled 4.3.0-2-stable. If this build is successfully packaged, it will be numbered and labeled 4.3.0-2-stable-1.

More builds could produce a sequence like:

  • 4.3.0-1-test-1
  • 4.3.0-2-stable-1
  • 4.3.0-3-test-1
  • 4.3.0-3-test-2 # Repackage 4.3.0-3-test-1 to add a missing library.
  • 4.3.0-4-test-1
  • 4.3.0-5-test-1
  • 4.3.0-7-stable-1 # 4.2.0-6-stable-1 failed to many tests to be published as a stable, so it was not published.
...
  • 4.3.0-25-test-1
  • 4.3.0-28-stable-1
  • 4.3.0-31-prerelease-1
  • 4.3.0-32-prerelease-1
  • 4.3.0-33-prerelease-1
  • 4.3.0-33-prerelease-2 # Repackaged 4.2.0-33-prerelease-1 to fix a file system layout issue.
  • 4.3.0-34-release-1
...
  • 4.3.1-1-release-1 # A user found a problem that must be fixed before the next release. A developer fixed it quickly.
  • 4.3.2-1-release-1 # Another user found another problem that must be fixed before the next release. A developer fixed it quickly.

There may be more gaps in published build numbers (B) than illustrated in this example.

Proposal 3

A blend of proposals by Jim Jacobs, Darrell Schiebel, and Scott Rankin.

Identification Scheme

  • CASA will use a 3 place sequence number X.Y.Z to identify a set of features and progress towards the next release.
    • X.Y, identifies a set of CASA features,
    • Z, a sequence number indicating progress towards the next release. 0 indicates first release of a set of features.
  • Rather than increment X and Y at the start of development for the next release, increment them at release time.
  • Increment Z to indicate progress towards the next release.

  • CASA will use a sequence number P to identify a packaged build. P starts at 1 and increments for each repackaging of the "same" build to fix an issue in a previously published package. For most packages, P will be 1.

All packages will be labeled as test, stable, pre-release, or release. This is discussed in CASA Package Naming.

An Example

The next CASA release will be 4.2.0. This was decided some time ago. Management does not have to decided if the features planned for the following CASA release constitute a major release or not until near release time.

The first package of the CASA development cycle from 2013-09 -- 2014-03 will be a test package. The first build will be numbered 4.2.1. If this build passes enough tests to be published as a test package, it will be labeled 4.3.1-test. If this build is successfully packaged, it will be numbered and labeled 4.2.1-test-1. Additional labels will be attached to packages for different Linux distributions and OS X versions as described in CASA Package Naming.

Assuming the next package of this development cycle will be a stable package. The second build will be numbered 4.2.2. If this build passes enough tests to be published as a stable package, it will be labeled 4.2.2-stable. If this build is successfully packaged, it will be numbered and labeled 4.2.2-stable-1.

More builds could produce a sequence like:

  • 4.2.1-test-1
  • 4.2.2-stable-1
  • 4.2.3-test-1
  • 4.2.3-test-2 # Repackage 4.2.3-test-1 to add a missing library.
  • 4.2.4-test-1
  • 4.2.5-test-1
  • 4.2.7-stable-1 # 4.2.6-stable-1 failed too many tests to be published as a stable, so it was not published.
...
  • 4.2.25-test-1
  • 4.2.28-stable-1
  • 4.2.31-prerelease-1
  • 4.2.32-prerelease-1
  • 4.2.33-prerelease-1
  • 4.2.33-prerelease-2 # Repackaged 4.2.0-33-prerelease-1 to fix a file system layout issue.

We decide CASA is ready for release, and management has decided the features planned for this release do not constitute a major release, so we number it CASA 4.3.

  • 4.3.0-release-1

Work starts on the next development cycle.

  • 4.3.1-test-1
  • 4.3.2-stable-1
  • 4.3.3-test-1
...
  • 4.3.10-test-1
  • 4.3.0-release-2 # A user found a problem that must be fixed before the next release. A developer fixed it.
  • 4.3.11-test-1
  • 4.3.0-release-3 # Another user found another problem that must be fixed before the next release. A developer fixed it quickly.
  • 4.3.12-test-1
  • 4.3.13-stable-1
...

Proposal 4

An attempt to simplify Proposal 1 by Scott Rankin.

Identification Scheme

This scheme reduces coupling between CASA project management, and what users care about most; which version of CASA includes tested version of features they require to reduce data. When CASA completes (code/debug/test/user acceptance test) a feature, we can announce that feature to users as "available in CASA X.0 or later".

  • CASA will use a 2 place sequence number X.Y to identify a CASA stable and test versions.
    • X.0 identifies a stable package.
    • X.Y, Y /= 0, identifies a test package with new code added to the previous X.0 stable package.
  • CASA will use a sequence number P to identify a packaged build. P starts at 1 and increments for each repackaging of the "same" build to fix an issue in a previously published package. For most packages, P will be 1.
  • CASA will no longer use the labels "test", "stable", "prerelease, "release".

CASA stable packages can either remain tied to the calendar, or (recommended) be updated when a major feature or set of features is complete.

An Example

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 labeled version 4.3.0 under the old scheme. Under the new scheme this would be labeled version 4.3. Following test packages would be version 4.4, 4.5, etc., until we have completed enough features and fixed enough bugs to create a stable package. That stable package would be labeled version 5.0., etc.

Package sequence

  • casa-4.3-1 - first test package of current development cycle.
  • casa-4.4-1 - second test package of current development cycle.
  • casa-5.0-1 - first stable package of current development cycle.
  • casa-5.0-2 - repackage of casa-5.0 to correct packaging issue.
  • casa-5.1-1 - first test package adding new code to casa-5.0 stable.
  • casa-5.2-1 - second test package adding new code to casa-5.0 stable.
  • casa-5.3-1

...

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-8.0-1 - last stable package of a development cycle. Features are now frozen for the release.
  • casa-8.1-1 - first bugfix package for release.
  • casa-8.2-1 - second bugfix package for release.
  • casa-8.3-1 - third bugfix package for release.
  • casa-9.0-1 - last stable package for a development cycle.

-- ScottRankin - 2014-02-13

Proposal 5

By Scott Rankin.

Identification Scheme

This scheme drops any pretense that version numbers have any meaning other than identifying a sequence in time.

  • CASA will use a two digit year and month, and a build sequence number to indicate development progress (YY.MM.S).
    • year and month (YY.MM), indicate when work started on that package.
    • the build sequence number (S) indicates the number of the package that month. The build sequence number starts at 1 each month.
  • CASA will use a sequence number P to identify a packaged attempt. P starts at 1 and increments for each repackaging of the "same" build (same source code version) to fix an issue in a previously published package. For most packages, P will be 1.
  • All packages will be labeled as test, stable, prerelease, or release as described in CASA Package Naming.

An Example

I am working on the first CASA test package for the next development cycle. Today is 2014-02-13, and we have not built any packages using this version scheme. So, this package would be version 14.2.0. The next package I build in 2014-02 would be version 14.2.1. It doesn't matter if I start that package the same day as 14.2.0, or a week later. The next package built in 2014-02 would be version 14.2.2, 14.2.3, etc..

Package sequence

  • casa-14.2.0-test-1 - The first CASA package built in 2014-02. It has passed enough tests to publish as a test package.
  • casa-14.2.1-test-1 - The second CASA package built in 2014-02. It has passed enough tests to publish as a test package.
  • casa-14.2.1-stable-1 - The CASA stable package for 2014-02 (assuming stable packages are tied to the calendar, not completed features).
    • Note: This package contains the same code as casa-14.2.1-test-1, but has been tested more thoroughly and shown it meets stable package quality requirements (TBD).
  • casa-14.2.2-test-1 - The next CASA test package.
  • casa-14.2.2-test-2 - The previous CASA test package, with packaging problems resolved.
  • casa-14.2.3-test-1 - The next CASA test package.
  • casa-14.2.4-test-1 - The next CASA test package.
  • casa-14.3.1-test-1 - The next CASA test package.
  • casa-14.3.2-test-1 - The next CASA test package.
  • casa-14.3.3-test-1 - The next CASA test package.
  • casa-14.3.4-test-1 - The next CASA test package.
  • casa-14.3.5-test-1 - The next CASA test package. Assuming for some reason none of the 2014-03 packages meet quality requirements for a stable package.
  • casa-14.4.1-test-1 - The next CASA test package.
  • casa-14.4.2-test-1 - The next CASA test package.
  • casa-14.4.2-stable-1 - The next CASA stable package.
    • Note: This package contains the same code as casa-14.4.2-test-1, but has been tested more thoroughly and shown it meets stable package quality requirements (TBD).
  • casa-14.4.3-test-1 - The next CASA test package.

...

  • casa-14.5.1-test-1 - The last CASA test package for the development cycle.
  • casa-14.5.1-stable-1 - The last CASA stable package for the development cycle.
    • Note: This package contains the same code as casa-14.5.1-test-1, but has been tested more thoroughly and shown it meets stable package quality requirements (TBD).
  • casa-14.5.2-prerelease-1 - The first CASA prerelease package for the development cycle.
  • casa-14.5.3-prerelease-1 - The second CASA prerelease package for the development cycle.
  • casa-14.5.3-release-1 - The CASA release package for the development cycle.
    • Note: This package contains the same code as casa-14.5.3-prerelease-1, but has passed all user acceptance testing.
  • casa-14.5.4-test-1 - The first CASA test package for the next development cycle.

-- ScottRankin - 2014-02-13

Proposal 6

A blend of Proposal 4 and comments from Darrell Schiebel.

Identification Scheme

This scheme reduces coupling between CASA project management, and what users care about most; which version of CASA includes tested version of features they require to reduce data. When CASA completes (code/debug/test/user acceptance test) a feature, we can announce that feature to users as "available in CASA X.0.0, or later".

  • CASA will use a 3 place sequence number X.Y.Z to identify a CASA stable and test versions.
    • X.0.0 identifies a "release" package that has passed User Acceptance Testing.
    • X.0.Z, Z/=0 identifies a critical bug fix to a released package.
    • X.Y.0, Y /= 0, identifies a stable package that
      • includes changes from X.0.0,
      • indicates development progress towards X+1.0.0,
      • has not yet passed User Acceptance Testing,
      • will not change for at least several weeks (unless a critical bug is detected and fixed), and
      • has been tested more thoroughly than a test package.
    • X.Y.Z, Z /= 0, identifies a test package that
      • includes changes from X.Y.0,
      • indicates development progress towards X.Y+1.0,
      • has not yet passed User Acceptance Testing, and
      • will be superseded in about one week.
  • CASA will use a sequence number P to identify a packaged build. P starts at 1 and increments for each repackaging of the "same" build to fix an issue in a previously published package. For most packages, P will be 1.
  • CASA will no longer use the labels "test", "stable", "prerelease, "release".

CASA release packages can either remain tied to the calendar or the development cycle, or (recommended) be updated when a major feature or set of features is complete and has passed User Acceptance Testing.

CASA stable packages can either remain tied to the calendar, or (recommended) be updated when a major feature or set of features is complete, but has not yet passed User Acceptance Testing.

An Example

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 labeled version 4.3.0 under the old scheme. Under the new scheme this would be labeled version 4.3.1. Following test packages would be version 4.3.1, 4.3.2, etc., until we have completed enough features and fixed enough bugs to create a stable package. That stable package would be labeled version 4.4.0., etc.

Package 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, 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.

...

After some progress towards the next "release".

  • casa-5.3.2-1 - A test package
  • casa-5.0.1-1 - The first critical bug fix to the previous "release" package.
  • casa-5.3.3-1 - Back to development for the next "release".

-- ScottRankin - 2014-02-14
Topic revision: r2 - 2014-02-26, ScottRankin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback