release-kit 0.9.10

A canonical release workflow: a technology-agnostic method, per-technology bindings, and the rk CLI that lands and serves them.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

[workspace]
changelog_update = true
# The bot's own release request has a release-plz-* head branch, which is
# exactly what the branch heuristic behind this default recognizes: the
# release half fires only on the push that lands that request's bump, so an
# ordinary work merge publishes nothing and the release decision stays on the
# one merge button.
release_always = false
publish = true # RK_IF_REGISTRY
# RK_IF_NO_REGISTRY # The crate publishes to no registry, so release-plz reads the last
# RK_IF_NO_REGISTRY # release from the v* tags that git_tag_name below writes, tags each
# RK_IF_NO_REGISTRY # release, and publishes nothing. release-plz refuses publish = true
# RK_IF_NO_REGISTRY # together with git_only = true, so the two change together.
# RK_IF_NO_REGISTRY publish = false
# RK_IF_NO_REGISTRY git_only = true
# This tag shape assumes one released package.
git_tag_name = "v{{ version }}"
# cargo-dist owns the GitHub release, because it is the half that has the
# installers to attach. release-plz creating it first leaves dist's host job
# failing on "a release with the same tag name already exists" and every
# release carrying no binaries. The tag stays release-plz's; git_tag_enable is
# separate and still on.
git_release_enable = false
# TODO(release-kit): keep false for a binary-only crate or a lib target only
# this crate's own tests link; set true when external consumers hold the API.
semver_check = false