Automating the process of cutting release will reduce the chance of making minor errors, reduce the cognitive load for release managers, and help us with more sustainable and rapid release cycle.
Currently the process of cutting a release involves the following manual steps:
- Generate the changelog with the appropriate version (e.g.,
3.21.0 or 3.22.2~alpha0)
- In the case it is a pre-release, we need to suffix the correct
alpha qualifier
- Commit the changelog entry at
[<version>] release, (e.g., [3.21.0] release or [3.22.2~alpha0] release)
- Run
dune-release to create and publish the release, on our repo and to the opam repo
- In the case of a pre-release, we need to use the new support for pre-releases to dune-release
Additionally, we must adjust and increment the version header in the changelog between pre-releases when revisions are needed and finally when cut the actual release. E.g., from the pre-release
## 3.22.2~alpha0 (2025-01-01)
we need to update to
This is a bit more finicky, since if we are backporting a change to fix a regression, we may need to also add the change into the version section in the changelog. I suggest we leave this part as manual initially, unless we have a simple solution for the happy path.
We'll need to account for bumping the versions as well.
Currently manual changes of this sort are required: #14333
Ali reports that
The doc changes use an idiom that helps us avoid having to bump many places
Starts with bumping the rpc version followed by dune test doc/ to see the things that need to be tweaked
We need to work out how we sequence release cutting and version bumping so that we can avoid commits falling into limbo, but also avoid needing a feature freeze on the trunk.
Automating the process of cutting release will reduce the chance of making minor errors, reduce the cognitive load for release managers, and help us with more sustainable and rapid release cycle.
Currently the process of cutting a release involves the following manual steps:
3.21.0or3.22.2~alpha0)alphaqualifier[<version>] release, (e.g.,[3.21.0] releaseor[3.22.2~alpha0] release)dune-releaseto create and publish the release, on our repo and to the opam repoAdditionally, we must adjust and increment the version header in the changelog between pre-releases when revisions are needed and finally when cut the actual release. E.g., from the pre-release
we need to update to
This is a bit more finicky, since if we are backporting a change to fix a regression, we may need to also add the change into the version section in the changelog. I suggest we leave this part as manual initially, unless we have a simple solution for the happy path.
We'll need to account for bumping the versions as well.
Currently manual changes of this sort are required: #14333
Ali reports that
We need to work out how we sequence release cutting and version bumping so that we can avoid commits falling into limbo, but also avoid needing a feature freeze on the trunk.