ST - Internals - Staging

Table of Contents


Versions

There are three versions of the code base:

Production
the final version, very much tested, intended for client use.
Beta
the version intended for use by computing support staff (i.e. CSCF and MFCF staff).
Debug
where changes are first made. In practice, for many years,

So this has been an alpha version by day, and a development version by night. Should daytime development start happening, then either the early adopters will have to switch to using the beta version, or a fourth version will be needed.

An important characteristic of how the debug version was being updated was that it was easy to very quickly undo any changes.

Not all of the code base has separate versions. E.g. there are various commands for which there is only a production version. And the package structure, and various data only have a production version. Beta and debug versions are created as needed. Making totally separate packages would solve that problem, however it would increase the complexity of the st-push command (described below).

Version Update Frequency

Once the debug version has had a sufficient test, usually two weeks minimum for simple changes, the production version is updated from the beta version, and the beta version is updated from the debug version. However, when the update of the beta version reveals a problem (via the larger test base), the correction is made to the debug version and then usually to the beta version right away; the production version isn't updated until the problem is resolved.

How to Update Versions

Update the Code

Before updating versions, verify that there are no checked out files, via

st-checked-out

The usual sequence of updates (each version updated by the previous) is done (on capo.private), via:

cd /software/rt-math-1
bury -r -f */{beta,production}
st-push production
st-push beta

The bury makes it easy to back out of an update, via

cd /software/rt-math-1
exhume -r */{beta,production}
batch sys_later -c "xh-dist-recurse rt-math-1"

Special Case — st-suid-perl

To "push" st-suid-perl requires rebuilding from source on each of the architecture specific distribution machines, via the xh-sdist command on capo.private. The Makefile has "beta" and "production" targets. E.g. to update production from beta, and beta from debug:

cd /usr/source/rt-math-1/st-suid-perl
xh-sdist -m "production beta"

Inform Staff

Then email is sent to describe the changes:

To: mfcf-staff@lists.uwaterloo.ca, scs-cscf-staff@lists.uwaterloo.ca
Subject: ST changes

The production version is being updated from the beta version.
The beta version is being updated from the debug version.
The visible changes in the beta version are:

=============================== ST #nnnnnn

  A description of the visible change caused by ST #nnnnnn

=============================== ST #nnnnnn

  ...

A starting point of the above can be obtained by the st-rlog command, to summarize the RCS logs created since the previously announced changes

Update ST Records

The summary field of the ST records describing the work above will contain a reference to which version each change is currently in. That needs to be updated. This is most easily done in the RunOn Sentence by selecting "a Summary" following the "Display" button (line 1) (which just adds "summary" to the fields to be displayed), selecting "ST" in the "about" selection (line 5), and using the query

EXPR: summary rlike 'beta|debug'

Records that were in beta are now recorded as in production, and then the record is closed. Records that were in debug are now recorded as in beta.

How to Distribute all Versions

Distribution to all of the machines that use ST code (www.cs, www.math, and the MX handlers for @cs and @math) is done via

batch sys_later -c "xh-dist-recurse rt-math-1"
which will force a distribution all of the way down the XHier distribution tree, sending email about the update at each point in the tree. Updates one level down the distribution tree will automatically happen each weekend (the XHier distribution default), however that's usually considered to be boringly slow.