chore(governance): update release steps

Signed-off-by: heitorlessa <[email protected]>

Author: heitorlessa

.github/workflows/publish.yml

@@ -4,36 +4,20 @@ name: Publish to PyPi
 #
 # === Manual activities ===
 #
-# 1. Document human readable changes in CHANGELOG (pre-generate unreleased changes with `make changelog`)
-# 2. Bump package version using poetry version <major|minor|patch|specific version>
-# 3. Merge version changes to develop branch
-# 4. Edit the current draft release notes
-# 5. If not already set, use `v<new version>` as a tag, and select develop as target branch
+# 1. Edit the current draft release notes
+# 2. If not already set, use `v<new version>` as a tag, e.g., v1.26.4, and select develop as target branch
 #
 # === Automated activities ===
 #
 # 1. Extract release notes tag that was published
-# 2. Ensure release notes tag match what's in CHANGELOG and pyproject
-# 3. Run tests, linting, security and complexity base line
-# 4. Publish package to PyPi test repository
-# 5. Publish package to PyPi prod repository
-# 6. Kick off Lambda Layer pipeline to publish latest version with minimal dependencies as a SAR App
-# 7. Kick off Lambda Layer pipeline to publish latest version with extra dependencies as a SAR App
-# 8. Builds a fresh version of docs including Changelog updates
-# 9. Builds latest documentation for new release, and update latest alias pointing to the new release tag
-# 10. Close and notify all issues labeled "pending-release" about the release details
+# 2. Run tests, linting, security and complexity base line
+# 3. Bump package version and generate latest Changelog
+# 4. Publish package to PyPi test and prod repository
+# 5. Kick off SAR App pipeline to publish latest version with minimal and extra dependencies
+# 6. Builds a new user guide and API docs with release version; update /latest pointing to newly released version
+# 7. Close all issues labeled "pending-release" and notify customers about the release
 
-#
-# === Fallback mechanism due to external failures ===
-#
-# 1. Trigger "Publish to PyPi" workflow manually: https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
-# 2. Use the version released under Releases e.g. v1.13.0
-#
-
-#
-# === Documentation hotfix ===
-#
-# Look for rebuild latest docs workflow
+# See MAINTAINERS.md "Releasing a new version" for release mechanisms
 
 on:
   release:

MAINTAINERS.md

@@ -169,23 +169,15 @@ Some examples using our initial and new RFC templates: #92, #94, #95, #991, #122
 
 ### Releasing a new version
 
-> TODO: This is an area we want to increase automation while keeping communication at human level.
+Firstly, make sure the commit history in the `develop` branch **(1)** it's up to date, **(2)** commit messages are semantic, and **(3)** commit messages have their respective area, for example `feat(logger): <change>`, `chore(ci): ...`).
 
-Firstly, make sure you are using the `develop` branch and it is up to date with the origin.
+**Found typos or unclear commit messages?**
 
-There are three main steps to release a new version: Changelog generation, version bumping, and drafting release notes.
+Reword through rebase and push with `--force-with-lease` once you're confident. This will ensure [CHANGELOG](./CHANGELOG.md) is always clear for customers looking to understand what changed in between releases - was that a bug? what new features and for which utility?
 
-#### Changelog generation
+**Looks good, what's next?**
 
-You can pre-generate a temporary CHANGELOG using `make changelog`. This will generate a `TMP_CHANGELOG.md` with all staged changes under the `unreleased` section.
-
-Each unreleased line item is a commit. You can adjust them if you find the commit titles are insufficient to describe their intent. Once you're comfortable, bring these changes to the `CHANGELOG.md` with a new version heading like in previous versions.
-
-#### Bumping the version
-
-Use `poetry version <major|minor|patch|specific version>` to bump the version. For example, you can use `poetry version minor` when releasing a minor version.
-
-NOTE. Make sure both `CHANGELOG` and `pyproject.toml` are committed and pushed to the remote `develop` branch before proceeding.
+The only step is to draft and publish a good release notes, everything else is automated.
 
 #### Drafting release notes
 
@@ -195,21 +187,27 @@ Make sure the `tag` field reflects the new version you're releasing, the target
 
 You'll notice we group all changes based on their [labels](#labels) like `feature`, `bug`, `documentation`, etc.
 
-> **Q: What if there's an incorrect title or grouping?**
+**I spotted a typo or incorrect grouping - how do I fix it?**
 
 Edit the respective PR title and update their [labels](#labels). Then run the [Release Drafter workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/release-drafter.yml) to update the Draft release.
 
-The best part comes now. Replace the placeholder `[Human readable summary of changes]` with what you'd like to communicate to customers what this release is all about. Always put yourself in the customers shoes. For that, these are some questions to keep in mind when drafting your first or future release notes:
+**All looking good, what's next?**
+
+The best part comes now. Replace the placeholder `[Human readable summary of changes]` with what you'd like to communicate to customers what this release is all about. Rule of thumb: always put yourself in the customers shoes.
+
+These are some questions to keep in mind when drafting your first or future release notes:
 
 - Can customers understand at a high level what changed in this release?
 - Is there a link to the documentation where they can read more about each main change?
-- Are there any graphics or code snippets that can enhance readability?
+- Are there any graphics or [code snippets](carbon.now.sh/) that can enhance readability?
 - Are we calling out any key contributor(s) to this release?
     - All contributors are automatically credited, use this as an exceptional case to feature them
 
-Once you're happy, hit `Publish release`. This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/publish.yml) and within a few minutes you should see the latest version in PyPi, and all issues labeled as `pending-release` will be notified.
+Once you're happy, hit `Publish release` 🎉🎉🎉.
+
+This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/publish.yml) and within a few minutes you should see the latest version in PyPi, and all issues labeled as `pending-release` will be closed and notified.
 
-> TODO: Wait for @am29d new Lambda Layers pipeline work to complete, then add how Lambda Layers are published
+> TODO: Include information to verify SAR and Lambda Layers deployment; we're still finalizing Lambda Layer automated deployment in GitHub Actions - ping @am29d when in doubt.
 
 ### Releasing a documentation hotfix