Try   HackMD

The Idealised GAP Release Process

The "idealized" release process we want to aim for could look like this (to be adapted as we try to do things); this assumes a branch stable-4.11 already exists; all of the following should be automated, possibly even in a single script

  1. commit & tag release in git
# the following should in the end be scripted!
# or done by a server for us
git checkout stable-4.11
# now edit configure.ac to set version to 4.11.3, and also set release day & year
make # may update some other files to have new version
git commit -m "Version 4.11.3" -a  # commit it all
git tag -m "Version 4.11.3" v4.11.3  # annotated tag, could also be signed in the future
git push
  1. At this point, manual work ideally is OVER and now a Travis CI job (or Github Actions, or whatever) takes over and performs all the following steps (but alternatively / initially, one can of course also do them manually, but we really DON'T WANT TO!!!)
  2. Upload current packages as "packages for 4.11.3"
    • involves downloading gap-packages-stable-4.11.tar.gz and re-uploading it as gap-packages-4.11.3.tar.gz
    • done by a script
    • (in the future, we may have a git repository with all deposited packages; then we'd just do git tag v4.11.3 in there)
  3. Create archives: run a script which takes a git ref (a sha1, a tag such "v4.11.3") as argument.
    • fetches the code from the given git ref in the GAP repository
    • fetches the versioned packages tarball
    • extracts packages in the code from git
    • build the GAP manual via make doc
    • (possibly regenerates packages manuals as well???)
    • remove LaTeX build artifacts
    • (possibly remove further files, e.g. the dev/ dir)
    • run tar to create .tar.gz (and perhaps also .tar.xz)
  4. Optional: generate binaries
    • e.g. create Windows binaries
    • create Flatpak/Snap for Linux???
    • Max still has that code for creating macOS binaries
  5. Upload the archives we just created to "some server"
    • upload to where? back to "our" server?
    • could instead or in addition create a GitHub release and upload there
    • for the latter, could use something like https://github.com/softprops/action-gh-release
    • (but then we are tied to GitHub Actions and can't do it manually; so perhaps a good old script is better after all?)
  6. Update the website:
    • generate a YAML file with all required info about the release suitable for the NEW Jekyll based website
    • run script which iterates over all packages and generates YAML files for each
    • put all these YAML files into the GapWWW repository
    • also commit and/or upload the GAP and GAP package manuals somewhere (HTML and PDF could go into different places)
    • commit and push all this into a branch and then open a pull request for that website update
    • this way, we retain control over the exact moment the website is updated online, and have a chance to review and check a few things first
    • possibly helpful for inspiration:
  7. If there is a problem at some point (e.g. a failure to download or upload; running out of disk space; error building manual; etc.), we must be able to detect it reliably so we notice it, and can deal with it
  8. Document everything thoroughly