@@ -13,6 +13,7 @@ This is the process to use to do a release:
13
13
2 ) Run the ` scripts/tag-release.sh ` script with latest release version number,
14
14
eg: ./tag-release.sh 1.2.3 to create and push a signed release tag. Note that it assumes that the
15
15
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.)
16
17
17
18
3 ) Wait for gitlab android-releaser to run the release job. If all goes well, it will automatically
18
19
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:
26
27
README.md, etc) that mentions the previous version. Make sure the badge in the top README.md
27
28
reflects the accurate upstream otel version.
28
29
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