Releases¶

Release cycle¶

release every 3 months (at time T)
T-11 weeks: all add your favorite Issues to the next-rel column
T-10 weeks: Scrum Master prep dev meet (internal)
- Update/trim next-release column in Kanban
- Prepare agenda, include possible additions not covered by Kanban/Issues
- Add milestone tags (nextver, nextver+1, etc.)
- Add highlighted new features to RELEASE_NOTES.md
T-8 weeks: Release Manager dev meet (external/public)
- Use Kanban as starter
- Move issues around based on input
- Add milestone tags, for this release or future releases
- Update highlighted new features to RELEASE_NOTES.md
T-1: all reserve week for wrapping up PRs and review.
T±0: Release Manager release!
- Have a look at Python release schedule, and time Arbor release optimally with new Python minor version. It is nice to generate wheels for the new minor as soon as minor is released.
T+1 weeks: Scrum Master retrospective
- set date for next release

These notes enumerate the steps required every time we release a new version of Arbor.

Check if some files are up to date
- README.md, ATTRIBUTIONS.md, CONTRIBUTING.md, RELEASE_NOTES.md
- Verify MANIFEST.in (required for PyPI sdist)
- Double check that all examples/tutorials/etc are covered by CI
- Check Python/pip/PyPi metadata and scripts, e.g. setup.py, pyproject.toml
Create new temp-branch ending in -rc. E.g. v0.6-rc
Bump the VERSION file:
- See also Version and build information
- Append -rc. (Make sure there’s no -dev)
Run all tests.
- ciwheel.yml triggers when you push a branch called ciwheel, and on new Git tags. Since we’ve not tagged the release yet, run git push origin HEAD:ciwheel. Make sure the tests pass.
  - ciwheel.yml pushes automatically to Test.PyPI.org. This only passes if ran as branch of the main arbor-sim repo (as that’s where the PyPI secret lives). On your own repo, the upload will fail (the rest should pass). If you want to test uploading, then force push to the _upstream_ ciwheel branch, e.g. git push upstream HEAD:ciwheel --force.
- If you want to test the PyPI submission (consider asking other OS-users):
```
python -m venv env && source env/bin/activate
pip install numpy
pip install -i https://test.pypi.org/simple/ arbor #should select the latest build, but doublecheck
python -c 'import arbor; print(arbor.__config__)'
```
- Use build flags to test the source package: Advanced options

Make sure no errors were encountered in the pre-release phase, working wheels were produced, and were installable from Test.PyPI.org and that no problems were reported.
Change VERSION. Make sure does not end with -rc or -dev.
Tag
- commit and open a PR for the above changes.
- on cmdline: git tag -a TAGNAME
- git push upstream TAGNAME
Create tarball with scripts/create_tarball ~/loc/of/arbor tagname outputfile
- eg scripts/create_tarball /full/path/to/arbor v0.5.1 ~/arbor-v0.5.1-full.tar.gz
Download output of wheel action associated to this release commit and extract (verify the wheels and source targz is in /dist)
- Of course, the above action must have passed the tests successfully.
Update spack/package.py. The checksum of the targz is the sha256sum.
Start a new release on Zenodo, this allocated a DOI, but you don’t have to finish it right away. Add new Zenodo badge/link to docs/README.
Create Github Release: https://github.com/arbor-sim/arbor/releases
- Go to GH tags and click “…” and “Create release”
- Categorize/edit Github’s autogenerated release notes (alternatively go through merged PRs to come up with a changelog).
- add tarball to release, created in previous step.

Upload to pypi & verify

twine upload -r arborpypi dist/*

python -m venv env && source env/bin/activate
pip install arbor
python -c 'import arbor; print(arbor.__config__)'

Update spack package / Ebrains Lab / Opensourcebrain
- Spack upstream: PR here
- Ebrains Lab: MR here
- OSB: update dockerfile if needed.
  - Make sure that Notebooks work on the version that their image is built with.