Skip to content

Commit

Permalink
docs(README): removes refrences to Angular convention. (#413)
Browse files Browse the repository at this point in the history
  • Loading branch information
jbottigliero authored and bcoe committed Jul 30, 2019
1 parent 4c5cad1 commit 29e7171
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions README.md
Expand Up @@ -353,13 +353,13 @@ Tell your users that you adhere to the Conventional Commits specification:

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

[`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.
[`semantic-release`](https://github.com/semantic-release/semantic-release) is described as:

`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.
> semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
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`.
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.

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.
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.

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

Expand Down

0 comments on commit 29e7171

Please sign in to comment.