letsencrypt
/
boulder
mirror of https://github.com/letsencrypt/boulder.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge 49850e935b into 473b4059c4

This commit is contained in:
Shiloh Heurich 2025-07-29 10:04:18 -07:00 committed by GitHub
parent 473b4059c4 49850e935b
commit ab06a53f64
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 16 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/release.md
View File

@ -1,7 +1,6 @@
# Boulder Release Process # Boulder Release Process
A description and demonstration of the full process for tagging a normal weekly A description and demonstration of the full process for tagging a normal weekly release and a hotfix release.
release, a "clean" hotfix release, and a "dirty" hotfix release.
Once a release is tagged, it will be generally deployed to Once a release is tagged, it will be generally deployed to
[staging](https://letsencrypt.org/docs/staging-environment/) and then to [staging](https://letsencrypt.org/docs/staging-environment/) and then to
@ -34,13 +33,16 @@ considered a guideline for normal releases but not a strict contract.
## Release Structure ## Release Structure
All releases are tagged with a tag of the form `release-YYYY-MM-DD[x]`, where As of 2025-06-30, releases are tagged with a tag of the form `v0.YYYYMMDD.N`, where
the `YYYY-MM-DD` is the date that the initial release is cut (usually the Monday the `YYYYMMDD` is the date that the initial release is cut (usually the Monday
of the current week), and the `[x]` is an optional lowercase letter suffix of the current week), and `N` is an integer indicating the hotfix number,
indicating that the release is an incremental hotfix release. For example, the starting at `0`. For example, a regular release might be `v0.20250707.0`, and
second hotfix release (i.e. third release overall) in the third week of January the first hotfix for that release would be `v0.20250707.1`.
2022 was
[`release-2022-01-18b`](https://github.com/letsencrypt/boulder/releases/tag/release-2022-01-18b). Historically, releases were tagged with the form `release-YYYY-MM-DD[x]`, where
`[x]` was an optional lowercase letter suffix for hotfixes. For example, the
second hotfix release (i.e. third release overall) in the third week of
January 2022 was [`release-2022-01-18b`](https://github.com/letsencrypt/boulder/releases/tag/release-2022-01-18b).
All release tags are signed with a key associated with a Boulder developer. Tag All release tags are signed with a key associated with a Boulder developer. Tag
signatures are automatically verified by GitHub using the public keys that signatures are automatically verified by GitHub using the public keys that
@ -75,9 +77,8 @@ tag message to just be a slightly more readable version of the tag name.
### Regular Releases ### Regular Releases
Simply create a signed tag whose name and message both include the date that the Simply create a signed tag. The `release/tag` tool will automatically
release is being tagged (not the date that the release is expected to be determine the correct tag name based on the current date.
deployed):
```sh ```sh
go run github.com/letsencrypt/boulder/tools/release/tag@main go run github.com/letsencrypt/boulder/tools/release/tag@main
@ -97,7 +98,9 @@ merged to `main` since the currently-deployed release was tagged.
In this situation, we create a new hotfix release branch starting at the point In this situation, we create a new hotfix release branch starting at the point
of the previous release tag. We then use the normal GitHub PR and code-review of the previous release tag. We then use the normal GitHub PR and code-review
process to merge the necessary fix(es) to the branch. Finally we create a new release tag at the tip of the release branch instead of the tip of main. process to merge the necessary fix(es) to `main` first. The fix commits are then
cherry-picked onto the release branch, typically via another pull request for
visibility. Finally we create a new release tag at the tip of the release branch instead of the tip of main.
To create the new release branch, substitute the name of the release tag which you want to use as the starting point into this command: To create the new release branch, substitute the name of the release tag which you want to use as the starting point into this command: