We seem to have settled (for ~6 years now) into the pattern
<decade>.<year>.<month mod 12>, so write a little check that validates
the given version against that expectation, allowing the Release
Manager to continue in the event of e.g. delayed release.
The normal release process now runs on a modern Linux, rather than a
carefully-preserved out-of-support Debian with ancient texinfo. Also
the #lisp channel topic has not been relevant for a good while.
This updates the SBCL build and release process to be more compatible
with distributed development -- to facilitate moving the upstream
repository into Git.
A detailed description of what is going on here is in
doc/GIT-WORKFLOW.md.
Some highlights:
* Drop version.lisp-expr and branch-version.lisp-expr.
* Auto-generate the version at build time using information
from Git, incorporating:
- Last release number.
- Number of commits on origin/master since last release.
- Current branch, if there are commits not on origin/master.
- Number of commits not on origin/master.
- SHA1 id of the last commit.
- Optional -dirty marker.
* Update release.sh to work with Git.
* Make source-distribution.sh exclude the .git directory from tarballs.
* Release tags contain NEWS for that release.
The script automates many of the tasks involved in performing the minimum
level of sanity checking that I am comfortable with, and enumerates others
that remain unscriptable despite 10 years of user interface "improvements"
at Sourceforge. It is unlikely to generalise to other release managers'
setups and taste without a little effort.
