This document describes the release process for Eiffel editions.
Look up the name of the next edition in the Versioning document.
GitHub milestones are used to track the proposed contents of an upcoming edition. Milestones are named "Edition <name>", e.g. "Edition Arica". Issues, not pull requests, are added to the milestone.
When all issues in the scope of the edition have been closed and it's time to make the release, follow these steps:
- Verify that all issues in the milestone are closed.
- Create a pull request with the following changes (see PR 277 for reference):
- Make sure history table entries with a missing
introduced_in
key get one that references the soon-to-be tag for the new edition. You can use yq to identify these files:for i in definitions/Eiffel*Event/*.yml ; do yq -e '._history | .[] | select(.introduced_in == null)' < $i > /dev/null 2>&1 && echo $i ; done
- Claim the edition in versioning.md, including a short summary of the changes in the edition.
- Add an entry for the new edition to generate_manifest.py. Unfortunately, this means that CI for the resulting commit won't succeed until the tag has been created (see next step).
- Make sure history table entries with a missing
- When the pull request has been merged, create and push an "edition-<name>" annotated tag (use
git tag -a
). The tag comment could include a short version of the included changes to the protocol. Any new major versions of event types should be called out. - Create a GitHub release based on the newly pushed tag. The tag comment can probably be reused as the release description.
- Create issue(s) for updating other repositories to reference the new edition:
- Announce the new edition on the eiffel-community mailing list, LinkedIn, and Slack and ask maintainers of other repositories to make necessary updates.
- Mark the edition's milestone as closed.