I assume that each commit on
main (default branch) is a possible release candidate. So my CI/CD pipeline looks at the
M.m.p version number in the codebase, and build & release artefacts (e.g. npm/Python packages, Docker images) with a
M.m.p.rc<commit_sha> tag (e.g.
A “release” is simply a commit on
main which has been tagged (patch versions dealt with a bit differently). The changelog should be updated only once per release.
Question: When should the
M.m.p version be bumped? On releases, or right after?
My ulterior motivation is to have it eventually all automated via
Approach 1: Bump on release commits
A release consists in one single commit that updates the changelog and bump the version to the value of the version/tag (example here).
- pros: one single commit to bump version + release.
- cons: “release candidate” versions don't make much sense, as
0.1.0has been released. (That's a blocker for me.)
Approach 2: Bump right after release
Right after a release, add a new tag which bumps the default version on
main. Release commit is simply about updating the changelog.
- pros: “.rc” versions now make sense,
- cons: a lot of extra clutter commits.
Approach 3: Set version on release commits
In this approach, the version in
0.0.0 and releases are done on specific branches, where the release commits update the changelog and set the version to the correct value (example here).
(note that the picture is misleading, as it doesn't show the separate branch.)
- pros: one-commit release,
- cons: un-informative version number for
main's “.rc” builds.