Closed JossWhittle closed 1 year ago
@ZinnurovArtur, @elmessary, @JackScanlon, @ieuans, @alexcoldea, @ChrisGreenSU, @shahzadmumtaz22, @DSThayer, @mr-possible, @SAIL-Ieuan
To clarify, we don't care what your commit messages on your branches look like. We just care that when you merge them into master
your Squash them and provide a proper commit message that will end up on master
.
Thanks for taking a look Joss.
We use Conventional Commit messages to trigger new versions. Here is the spec https://www.conventionalcommits.org/en/v1.0.0/
These commit messages are a blend between being human readable and meaningful, and being machine readable and information rich.
An example commit message might be:
This commit message indicates a new feature is being added. What type of release should this create?
These are the release rules that we use by default:
So you can see that our example
feat: blah
commit message is going to trigger aminor
release. That is,1.1.5
would be bumped to1.2.0
.Use a relevant commit type (
feat
/fix
/refactor
/chore
/ci
) that indicates clearly what it is you are trying to change about the state of themaster
branch.In order to generate new releases commits merged into the
master
branch must have Conventional Commit messages.master
has branch protection, meaning you must merge intomaster
using a Pull Request.master
usingSquash and Merge
commits.master
.feat: Added new foobar feature to the bazbiz module
feat/add-foobar-to-bazbiz