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 development)
What is your primary goal?
Section titled “What is your primary goal?”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?
Section titled “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 of that 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 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?
Section titled “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 and 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
and 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?
Section titled “Is the branching strategy of your project supported by semantic-release?”Before adopting semantic-release, confirm that your team’s branching model is compatible.