semantic-release

Semantic Versioning is difficult for a lot of people and somewhat error prone. This automates the process, given the commit messages follow a certain template (see below), allowing automation of the process in a pipeline or something.

Supported project types

• Cargo (Cargo.toml)
• NPM (package.json)

Is this ready for general use

Most likely not, I’d recommend semantic-release/semantic-release for most people. My tool works fine for my use cases but I can’t speak for anything else. Might work well, might delete everything you love and cherish, be careful.

The commit template

This is somewhat based on the Angular Commit Message Format but not as extensive.

Every commit that counts towards a new release should have a summary starting with something like this:

<type>(<scope>): <summary>

The type field is mandatory, scope is optional. summary is where the usual commit message would go. The scope field doesn’t really have a semantic purpose but may be used to categorize commits into certain features/parts of the project.

Supported values for type are:

• feat: Marks a new feature or general improvement, this will lead to a bump in the MINOR version
• fix: A bug fix, this will lead to a bump in the PATCH version

Breaking changes can be marked by putting the String BREAKING CHANGE: somewhere in the commit message body. This will override whatever type was given and lead to a bump in the MAJOR version

How do I use this

cargo run -- --help

Getting started

semantic-release provides the --init option to generate a template config file at the given location. Use it like this:

semantic-release --init path/to/project.toml

The config file can be placed wherever you like. I suggest the root of the git repo.

The generated file will look like this:

cat ./src/init/project.toml

Monorepo

You can easily support a monorepo by creating multiple config files that point at the different subprojects.

TODOs

• give better feedback to the user

Maybe planned features

• Write a Changelog file. This might be better handled by an additional tool.
• prebuilt binaries

Not happening here

• git push. This would disable the ability to amend the commit with whatever the CI/CD process needs to do
• Publish to NPM/Cargo/Maven/Whatever
• Dependent package support (b depends on a so a bump for a should also update & bump b) for monorepos
• prebuilt mac binaries. I don’t have a device for that