From c0963950c213a899ea94c9476dfc6220c8adcfcb Mon Sep 17 00:00:00 2001 From: Jon Cursi Date: Thu, 26 Sep 2024 15:55:20 -0400 Subject: [PATCH] [E4E-0]: Updated readme docs --- README.md | 50 +++++++++++++++++++++++++++++++++----------------- 1 file changed, 33 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index db30ed1..46c0593 100644 --- a/README.md +++ b/README.md @@ -145,26 +145,42 @@ Here are some of the more important ones: ### Release Process -Upon merge, [`semantic-release`](https://github.com/semantic-release/semantic-release) -will scan the `main` branch for new commits and will use those commits to choose -a new version for this library and write automated changelog documentation. Thus, -it is important that we accurately capture what type of development we are -doing via our commit messages. +When your code changes are ready, it's time to publish a new patch, minor, or +major release. -- For changes to documentation, use the `docs` tag: +1. Make a PR (or mark your draft PR as ready for review). -```bash -git commit -m "docs: Updated documentation to clarify XYZ" -``` +2. Annotate your PR with the necessary context to let Semantic Release know if + this should yield a new patch, minor, or major release: -- For patches, use `fix`: + - If you expect the merging of your PR to result in a new _patch_ release, + start your PR title with `fix:`. -```bash -git commit -m "fix: Updated an eslint rule to fix false positives in downstream projects" -``` + - If you expect the merging of your PR to result in a new _minor_ release, + start your PR title with `feat:`. -- For new functionality, use `feat`: + - If you expect the merging of your PR to result in a new _major_ release, + see #3 below for details. -```bash -git commit -m "feat: Added new eslint rules around async/await and promises" -``` + - If you expect the merging of your PR to skip the creation of a new release, + you can start your PR title with `build:` (for build changes), + `chore:` (for basic maintenance), `docs:` (for documentation updates), + or simply do not use any of the above keyword prefixes. + +3. If the pull request should create a new major version release, the string + `BREAKING CHANGE:` must be included in at least one commit message's + **footer** ([see docs](https://semantic-release.gitbook.io/semantic-release#commit-message-format)) + — Semantic Release's commit analyzer does **not** use the PR title in + determining major releases. + + You can either manually add `BREAKING CHANGE:` to the commit footer + after pressing "Merge Pull Request"/"Squash and Merge" in your PR (in the + "optional extended description" field). Alternatively, if you're merging the + PR by creating a new merge commit, ensure that at least one of the source + commits' messages has `BREAKING CHANGE:` in its footer. Note that to + accomplish this you may need to commit with the `--no-verify` flag to bypass + commitlint. + +4. Once your PR is merged, Semantic Release will pick it up and initiate the + automated release process. If it detects that it should create a release + (based on the above), it will. Otherwise, it won't!