From cb82383ef3bc814f7a315e8ef2ee22673544ba33 Mon Sep 17 00:00:00 2001
From: Surbhi A <138259843+surbhiia@users.noreply.github.com>
Date: Mon, 9 Dec 2024 12:59:19 -0800
Subject: [PATCH] Update main with changelog notes for 1.8.1 + update
 releasing.md with patch release steps (#1106)

---
 CHANGELOG.md |  4 ++++
 RELEASING.md | 17 ++++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index c841b1a9..f0437555 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -7,6 +7,10 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Unreleased
 
+### Version 1.8.1 - 2024-12-06
+
+Reducing the version of androidx libraries that enforce API level 35.
+
 ### Version 1.8.0 - 2024-12-04
 
 This is a regular maintenance release.
diff --git a/RELEASING.md b/RELEASING.md
index 5ab8303a..8053d014 100644
--- a/RELEASING.md
+++ b/RELEASING.md
@@ -13,6 +13,7 @@ This is the process to use to do a release:
 2) Run the `scripts/tag-release.sh` script with latest release version number,
    eg: ./tag-release.sh 1.2.3 to create and push a signed release tag. Note that it assumes that the
    remote is named `origin`, if you named yours differently you might have to push the tag manually.
+   (Following step 4 should manually push the tag.)
 
 3) Wait for gitlab android-releaser to run the release job. If all goes well, it will automatically
    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:
    README.md, etc) that mentions the previous version. Make sure the badge in the top README.md
    reflects the accurate upstream otel version.
 
-6) Go to Slack and notify relevant about release
+6) Go to Slack and notify relevant channels about the release.
+
+## Releasing a patch version for a previously released version
+
+1) If not already available, create a branch from the tag of the previously released version for
+   which you're creating the patch. For example, create a v1.8.x branch. All changes for the patch
+   release should be made on this branch.
+
+2) Follow steps 1 to 4 outlined in the "Releasing a New Version" section.
+
+3) Update the `main` branch with similar fixes. This PR can and probably should also include updating
+   any documentation (CHANGELOG.md, README.md, etc) to reflect the version you just released. Make
+   sure the badge in the top README.md reflects the accurate upstream otel version.
+
+4) Go to Slack and notify relevant channels about the release.