Releases¶
This page is to help core developers in releasing a new version of aeon
.
Core developers making a release should have write access to the repository.
aeon
aims for a release every one or two months currently, based on the amount of
new content available for the release.
Preparing the release version¶
The release process is as follows, on high-level:
Ensure deprecation actions are carried out. Deprecation actions for a version should be marked by “version number” annotated comments in the code. E.g., for the release
0.10.0
, search for the string0.10.0
in the code and carry out described deprecation actions. PRs performign deprecation actions should start with [DEP] and use thedeprecation
label. So they are put under the “Deprecations” section in the release notes.Create a “release” pull request. Create a branch from main and PR named after the release version. This should make changes to the version numbers (root
__init__.py
,README.md
andpyproject.toml
) and have complete release notes in the changelog webpage. See the release notes section for more details.Merge the “release” pull request. This PR should ideally be the final PR made before the release with the exception of any necessary troubleshooting PRs. The PR and release notes should optimally be reviewed by multiple core developers, then merged once tests pass.
Create the GitHub release. This release should create a new tag following the syntax v[MAJOR].[MINOR].[PATCH], e.g., the string
v0.10.0
for version0.10.0
. The release name should similarly beaeon v0.10.0
. The GitHub release notes should contain only “hightlights”, “new contributors” and “all contributors” sections, and otherwise link to the release notes in the changelog, following the pattern of current GitHub release notes. The full GitHub commit log between releases can also be included.
pypi
release and release validation¶
Creation of the GitHub release trigger the pypi
release workflow.
Wait for the
pypi
release CI/CD to finish. If tests fail due to sporadic unrelated failure, restart. If tests fail genuinely, something went wrong in the above steps, investigate, fix, and repeat. If the bug is known and sporadic (i.e. failure to read data from an external source), the release workflow can be restarted. It is not necessary to create a new GitHub release, and the workflow can be manually run from the GitHub Actions tab if more PRs are required.Release workflow completion tasks. Once the release workflow has passed, check
aeon
version onpypi
, this should be the new version. A validatory installation ofaeon
in a new Python environment should be carried out according to the installation instructions. If the installation does not succeed or wheels have not been uploaded, action to diagnose and remedy must be taken.
conda-forge
release and release validation¶
Merge the
conda-forge
release PR. After some time a PR will be automatically created in the aeon conda-forge feedstock. Follow the instructions in the PR to merge it, making sure to update any dependencies that have changed and dependency version bounds.
Release notes¶
Generally, release notes should follow the general pattern of previous release notes. The initial change notes can be generated by running .github/utilities/changelog_generator.py. Pull requests will be put into sections in the release notes based on the labels, so ensure that the PRs are labelled correctly.
After generating the initial release notes, make sure to:
Add the release version and month/year of the release at the top of the release notes
Add any important announcements at the top of the release notes if applicable
Add release highlights section
Tidy the auto-generated PR list, moving PRs as necessary so they are correctly categorised. It may be easier to re-label PRs and regenerate the release notes.
Ensure the contributors section is correct
Emergency release workflow¶
If a release is required urgently, the release testing process can be expedited by running the “Fast release” workflow. This workflow should not be used under normal circumstances. Any issues with release testing should be addressed in the normal release workflow if possible. Consult the core developers on Slack before running this in any circumstance.