docs: include milestones and labels with release steps #63
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #63 +/- ##
=======================================
Coverage 94.68% 94.68%
=======================================
Files 11 11
Lines 207 207
=======================================
Hits 196 196
Misses 11 11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -89,14 +89,17 @@ This project uses [mypy](https://mypy.readthedocs.io/en/stable/index.html) to ch | |||
| If you want to test the package locally you can. | |||
|
|
|||
| 1. Build the package locally | |||
|
|
|||
There was a problem hiding this comment.
🔍 Autoformatting from the editor but no change to rendered markdown outputs AFAICT!
There was a problem hiding this comment.
One of the oldest ideas on my task list is to find a markdown formatter that we could use across all our projects, everyone seems to have their own 🤔
There was a problem hiding this comment.
I would be so glad to share a matching formatter for sake of a consistent edits! It's sometimes difficult to ignore the unstaged changes this can cause otherwise...
| - Commit with a message including the new version number. For example `1.2.3` | ||
| & Push the commit to a branch and create a PR to sanity check. | ||
| - `git checkout -b 1.2.3-release` | ||
| - `git commit -m 'version 1.2.3'` | ||
| - `git commit -m 'chore(release): tag version 1.2.3'` |
There was a problem hiding this comment.
👁️🗨️ Preferring the conventional commit here: https://www.conventionalcommits.org/en/v1.0.0/
There was a problem hiding this comment.
Nice 💯 I like this
| - Commit with a message including the new version number. For example `1.2.3` | ||
| & Push the commit to a branch and create a PR to sanity check. | ||
| - `git checkout -b 1.2.3-release` | ||
| - `git commit -m 'version 1.2.3'` | ||
| - `git commit -m 'chore(release): tag version 1.2.3'` |
There was a problem hiding this comment.
Nice 💯 I like this
| - Merge in release PR after getting an approval from at least one maintainer. | ||
| 2. Create a new GitHub Release from the | ||
| [Releases page](https://github.com/slackapi/python-slack-hooks/releases) by | ||
| clicking the "Draft a new release" button. | ||
| 3. Input the version manually into the "Choose a tag" input. You must use the | ||
| same version found in `slack_bolt/version.py` | ||
| same version found in `slack_cli_hooks/version.py` |
|
@WilliamBergamin Thanks for the review and wonderful release process that we have on this project! I'll stay tuned for markdown formatting changes to come, but for now we can merge this following the |
Summary
This PR includes GitHub milestones and labels with the release steps of the
MAINTAINERS_GUIDE.mdto match related projects.Preview
📚 https://github.com/slackapi/python-slack-hooks/blob/zimeg-docs-maintainers-guide-release/.github/maintainers_guide.md
Requirements
./scripts/install_and_run_tests.shafter making the changes.