release every 3 months (at time
alladd your favorite Issues to the next-rel column
Scrum Masterprep 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
Release Managerdev 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
allreserve week for wrapping up PRs and review.
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.
set date for next release
These notes enumerate the steps required every time we release a new version of Arbor.
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.
VERSION. Make sure does not end with
Merge the PR.
commit and either reuse the draft PR for the RC, or open a new one.
once merged, make and push tag.
git tag -a TAGNAME
git push upstream TAGNAME
Upload to pypi & verify
Get the wheels from test PyPI or the Github Action that produced the release artifacts.
twine upload -r arborpypi dist/* python -m venv env && source env/bin/activate pip install arbor python -c 'import arbor; print(arbor.__config__)'
Create Github Release: https://github.com/arbor-sim/arbor/releases
The Github action that produced the release artifacts should have prepared a draft Release.
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).
Manually build full tarball:
scripts/create_tarball ~/loc/of/arbor tagname outputfile
scripts/create_tarball /full/path/to/arbor v0.5.1 ~/arbor-v0.5.1-full.tar.gz
Place the Github generated release notes in
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.
Update Zenodo with authors and changelog created in previous step and submit.
Make a new PR setting
VERSIONto the next with a trailing
-dev. E.g. if you just release
spack/package.py. The checksum of the targz is the sha256sum.
Include changes such as to
doc/index.rstin postrel PR. Copy Zenodo BibTex export to
scripts/check-all-tags.shto check the current tag.
Update spack package / Ebrains Lab / Opensourcebrain
Spack upstream: PR here
Ebrains Lab: MR here
OSB: update requirementsfile if needed.
Make sure that Notebooks work on the version that their image is built with.
Announce on our website
Announce on HBP newsletter firstname.lastname@example.org, HBP Twitter/socials email@example.com
[AUTOMATED] Add tagged version of docs on ReadTheDocs
HBP internal admin
TC Wiki: https://wiki.ebrains.eu/bin/view/Collabs/technical-coordination/EBRAINS%20components/Arbor/
Update howto: https://wiki.ebrains.eu/bin/view/Collabs/swc-guide#HHowtoupdateexistingSoftwareinstances
tldr: shoot your ticket here: firstname.lastname@example.org
Supported file formats
Send an update to the folk in charge of HBP Twitter if we want to shout about it
Release automation is a bit more advanced for Arbor GUI: the act of pushing a new tag, auto-drafts a release with the relevant artifacts. The post release steps mentioned above are largely the same. A list of the places where an update must be entered: