Skip to content

Commit cb82383

Browse files
authored
Update main with changelog notes for 1.8.1 + update releasing.md with patch release steps (#1106)
1 parent b6d1558 commit cb82383

File tree

2 files changed

+20
-1
lines changed

2 files changed

+20
-1
lines changed

CHANGELOG.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,10 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
77

88
### Unreleased
99

10+
### Version 1.8.1 - 2024-12-06
11+
12+
Reducing the version of androidx libraries that enforce API level 35.
13+
1014
### Version 1.8.0 - 2024-12-04
1115

1216
This is a regular maintenance release.

RELEASING.md

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@ This is the process to use to do a release:
1313
2) Run the `scripts/tag-release.sh` script with latest release version number,
1414
eg: ./tag-release.sh 1.2.3 to create and push a signed release tag. Note that it assumes that the
1515
remote is named `origin`, if you named yours differently you might have to push the tag manually.
16+
(Following step 4 should manually push the tag.)
1617

1718
3) Wait for gitlab android-releaser to run the release job. If all goes well, it will automatically
1819
close and release the "staging" repository...which means the build has been published to sonatype
@@ -26,4 +27,18 @@ This is the process to use to do a release:
2627
README.md, etc) that mentions the previous version. Make sure the badge in the top README.md
2728
reflects the accurate upstream otel version.
2829

29-
6) Go to Slack and notify relevant about release
30+
6) Go to Slack and notify relevant channels about the release.
31+
32+
## Releasing a patch version for a previously released version
33+
34+
1) If not already available, create a branch from the tag of the previously released version for
35+
which you're creating the patch. For example, create a v1.8.x branch. All changes for the patch
36+
release should be made on this branch.
37+
38+
2) Follow steps 1 to 4 outlined in the "Releasing a New Version" section.
39+
40+
3) Update the `main` branch with similar fixes. This PR can and probably should also include updating
41+
any documentation (CHANGELOG.md, README.md, etc) to reflect the version you just released. Make
42+
sure the badge in the top README.md reflects the accurate upstream otel version.
43+
44+
4) Go to Slack and notify relevant channels about the release.

0 commit comments

Comments
 (0)