# 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

2. 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!!!)
3. 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)
4. 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`)
5. Optional: generate binaries
- e.g. create Windows binaries
- create Flatpak/Snap for Linux???
- Max still has that code for creating macOS binaries...
6. 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?)
7. 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:
- https://github.com/BryanSchuetz/jekyll-deploy-gh-pages uses an GitHub Action to push to a branch
- https://github.com/marketplace/actions/create-pull-request
8. 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
9. Document everything thoroughly