Skip to content

Commit 29e7171

Browse files
jbottiglierobcoe
authored andcommitted
docs(README): removes refrences to Angular convention. (#413)
1 parent 4c5cad1 commit 29e7171

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

README.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -353,13 +353,13 @@ Tell your users that you adhere to the Conventional Commits specification:
353353

354354
### How is `standard-version` different from `semantic-release`?
355355

356-
[`semantic-release`](https://github.com/semantic-release/semantic-release) is a fully automated library/system for versioning, changelog generation, git tagging, and publishing to the npm registry.
356+
[`semantic-release`](https://github.com/semantic-release/semantic-release) is described as:
357357

358-
`standard-version` is different because it handles the versioning, changelog generation, and git tagging for you **without** automatic pushing (to GitHub) or publishing (to an npm registry). Use of `standard-version` only affects your local git repo - it doesn't affect remote resources at all. After you run `standard-version`, you still have the ability to review things and correct mistakes if you want to.
358+
> semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
359359
360-
They are both based on the same foundation of structured commit messages (using [Angular format](https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md)), but `standard-version` is a good choice for folks who are not yet comfortable letting publishes go out automatically. In this way, you can view `standard-version` as an incremental step to adopting `semantic-release`.
360+
While both are based on the same foundation of structured commit messages, `standard-version` takes a different approach by handling versioning, changelog generation, and git tagging for you **without** automatic pushing (to GitHub) or publishing (to an npm registry). Use of `standard-version` only affects your local git repo - it doesn't affect remote resources at all. After you run `standard-version`, you can review your release state, correct mistakes and follow the release strategy that makes the most sense for your codebase.
361361

362-
We think they are both fantastic tools, and we encourage folks to use `semantic-release` instead of `standard-version` if it makes sense for them.
362+
We think they are both fantastic tools, and we encourage folks to use `semantic-release` instead of `standard-version` if it makes sense for their use-case.
363363

364364
### Should I always squash commits when merging PRs?
365365

0 commit comments

Comments
 (0)