Version and release procedures use Perforce

[rptb1]

The version create, and release build procedures are specific to Ravenbrook's Perforce.

Ravenbrook needs them updated in order to migrate to Git and GitHub (see #98 ).

They need to be useful to other FOSS developers of the MPS.

[rptb1]

We should also examine the Python programs related to branch and release procedure:

• tool/branch
• tool/release
• [Search for others.]

Unfortunately, it may be best to delete these if they aren't relevant to Git.

[rptb1]

The new procedure must ensure the relevant version of the manual is built, published, and linked. See #141 .

[UNAA008]

The version-create procedure currently assumes that there is an up to date plan or list of requirements to be satisfied by the version branch and that there is a single thread of numbered versions. There's no mention of other forms of versioning that may happen with a more distributed set of interested parties developing with he MPS as a component. Issue #126 may be relevant to this, depending on the intended life cycle. The procedure requires an update to the master version of code/version.c, which would be awkward if there are parallel version branches active. Arguably we should solve the version threading problem when it actually arises, but we should at least note it. The planning problem is a separate Issue to be raised somewhere.

[UNAA008]

The table of versions is updated by the version-create procedure. This is currently part of the MPS project tree at Ravenbrook and not curently updateable from outside.

[rptb1]

The version-create procedure currently assumes that there is an up to date plan or list of requirements

We could bring https://www.ravenbrook.com/project/mps/plan/ in to the repo. See also #95.

[rptb1]

Updating the release procedure must also update manual/build.txt and possibly readme.txt. See https://github.com/Ravenbrook/mps/blob/40f23128c2bcddd17aadc0c4c3369e6473c754a1/manual/build.txt?plain=1#L17-L20

[rptb1]

The new procedure must ensure the relevant version of the manual is built, published, and linked. See #141 .

The work in #141 will cause the latest version (from master) of the manual to appear at https://memory-pool-system.readthedocs.io/ . That's probably correct for now (since Read the Docs can't build 1.117) but the version or release procedure should include updating the Read the Docs configuration so that the canonical URL above points at something stable, such as the latest version branch. And whatever other changes make sense for creating URLs for releases.

[rptb1]

The release procedure should ensure that the tag in GitHub (and Git?) links to the appropriate URL describing the release.

[rptb1]

@UNAA008 Ensure that the release procedure includes applying all available tests (if it doesn't already) including the MMQA test suite on the commercial clients' hardware, and the clients' tests. This mitigates the need for #106 .

[rptb1]

clients' tests

Client software should be run with the cool variety as well as hot, and possibly rash to check for performance regressions in hot.

[rptb1]

We made release 1.118.0 on 2023-07-11 by adapting our existing version and release procedures to Git and GitHub on the fly. Our internal notes from the experience are in Notes from making version 1.118 and release 1.118.0. These should be used as source material for updating the procedures.