Release Process - ALF — Algorithms for Lattice Fermions

How ALF releases are managed.

Release Cycle¶

Minor releases in April and October each year
Major releases approximately every 3–4 years, accompanied by a documentation paper

Versioning¶

ALF uses semantic-style versioning (MAJOR.MINOR). Major bumps indicate significant API or algorithmic changes; minor bumps cover new features, model additions, and improvements. Version metadata is tracked in:

CITATION.cff — structured citation metadata
CHANGELOG.md — detailed log of changes per version
Documentation LaTeX variable \ALFver

Release Checklist¶

Tests pass. Ensure all CI pipelines (test-branch, test-vs-ed) are green across all supported environments (GNU, Intel, PGI, macOS).
Documentation up to date. Check that the LaTeX documentation paper reflects any new features or API changes.
CHANGELOG.md up to date. All merged changes since the last release should be listed with author and merge request reference.
Create release branch. Branch ALF-X.Y from master.
Update version strings. Set \ALFver in the documentation, update CITATION.cff.
Update README. Add the version number, remove any development warning.
Update master. Add a development warning to master’s README pointing to the release branch.
Companion repos. Create corresponding branches in pyALF and the Tutorial repository.
Announce. Update the ALF website and post to Discord.

CI / CD¶

Two GitHub Actions workflows support the release process (both workflow_dispatch):

Workflow	Purpose
`test-branch.yaml`	Compare a feature branch against master using `alf_test_branch`; matrix across Debian (GNU), Intel, PGI, macOS
`test-vs-ed.yaml`	QMC vs exact diagonalization regression; prepare → simulate → analyze pipeline

Both use Docker containers from ghcr.io/alf-qmc/alf-container/ for reproducible environments.