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

mps/manual/build.txt

Lines 17 to 20 in 40f2312

	Getting hold of the MPS Kit
	---------------------------
	Download the latest MPS Kit release from `<https://www.ravenbrook.com/project/mps/release/>`_.

[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.