python-betterproto
python-betterproto copied to clipboard
Configure Semantic Release
If we use Semantic Release to release this repository, we'll get automatically-incremented releases, version tags, and changelogs on each merge to master
, at the low cost of having to follow a commit prefix convention. This takes minimal configuration:
- a semantic release config (in
package.json
) - a couple of lines in the release CI task to dispatch SemRel and possibly access to the credentials it needs to commit tags back to the repo
- [optional] a dry-run task in PR pipelines to show committers what to expect on merge
We also have the option, which I'd recommend, of using their rc
branch pattern:
- all PRs target the
rc
branch, notmaster
. - On merge to
rc
, PRs release a newrc
version for the next applicable version. For example, if we were to start followingv2.0.0
, a PR whose commits trigger a minor release would be taggedv2.1.0rc0
. - Full versions are released simply by merging
rc
intomaster
- no other chores needed. Then,v2.1.0rc0
would becomev2.1.0
.
I'd like to amend this proposal - the rc
branch, in practice, is unintuitive for many and causes problems which need manual resolution.
A better option: publish rc
versions automatically on every merge to master
; publish full versions using a manually-triggered task, so we choose when to release but don't need to do any more than kick off a task.
More a heads up that anything - SemVer in practice is not necessarily always compatible with PEP440.