There are three versions of the code base:
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).
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.
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"
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"
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
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.
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.