mirror of
https://github.com/semantic-release/semantic-release.git
synced 2026-10-26 16:09:37 +00:00
Matt Travi
39 lines
2.8 KiB
Markdown
39 lines
2.8 KiB
Markdown
# Considerations
|
|
|
|
**semantic-release** is
|
|
|
|
- an opinionated release tool
|
|
- a tool to simplify versioning releases semantically first, automating steps related to a release process second
|
|
- a tool that encourages engineering practices that support delivering high quality at a sustainable pace (continuous deployment/release, trunk based deployment)
|
|
|
|
## Are you interested in **semantic-release** because of our primary or secondary goals
|
|
|
|
If your primary attraction is for automatic release note generation rather than semantic versioning, you may want to reconsider if **semantic-release** is the right fit for your goals.
|
|
|
|
## Do you actually need semantic versioning?
|
|
|
|
The use of the word "semantic" in the term "semantic versioning" has the intent that the structure of the version conveys specific meaning.
|
|
Consult https://semver.org/ for details about the details of the specific meaning, but keep in mind that the semantics are from the perspective of a consumer.
|
|
|
|
Semantic versioning is most useful for software releases that are consumed programmatically.
|
|
Common examples are libraries/packages consumed as dependencies.
|
|
Base Docker images can also fall in this category because they are consumed in a way that other layers build on top of them.
|
|
|
|
Applications that are deployed directly to a runtime environment lack an audience to benefit from the benefits of semantic versioning.
|
|
Docker images that are published to a registry only for the purpose of deploying directly to a runtime environment fall into this category, even though they are a published asset.
|
|
Often, using the git SHA as the version for such assets is a better choice than versioning them semantically.
|
|
|
|
## Can you simplify the release steps automated by **semantic-release**?
|
|
|
|
Updating the version in the `package.json` of an npm package or providing release notes in a `CHANGELOG.md` file are popular release steps
|
|
that can be enabled with **semantic-release** using the [changelog](https://github.com/semantic-release/changelog) and [git](https://github.com/semantic-release/git) plugins.
|
|
However, those two plugins are intentionally _not_ included in the default configuration of **semantic-release** because
|
|
[they are not necessary for **semantic-release** to function](https://semantic-release.gitbook.io/semantic-release/support/faq#it-is-not-needed-for-semantic-release-to-do-its-job)
|
|
and [making commits during the release process adds significant complexity](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity).
|
|
|
|
Please consider the trade-offs of adding those plugins to your release configuration for potentially unnecessary goals.
|
|
|
|
## Is the branching strategy of your project supported by **semantic-release**?
|
|
|
|
[supported branching strategies](./supported-branching.md)
|