> Reopens [#431](#431), which
could not be reopened after its branch moved. Same change, plus a second
package. **Base of the provider-conformance stack**:
[#423](#423) (assets) →
[#439](#439) (Appendix F) →
[#425](#425) (report schema)
stack on this, but it stands on its own and can merge alone.

## What

Sets up [release-please](https://github.com/googleapis/release-please)
to cut the specification's releases, replacing the manual tagging step.

## Why

The `vX.Y.Z` tags are created by hand. That is easy to postpone — v0.9.0
went out in July and the commits since it are unreleased — and it
assembles the changelog from whoever's memory is handy. release-please
proposes the version and the notes as a pull request, and tags once that
pull request is merged.

## What does not change

| | before | after |
|---|---|---|
| tag | `v0.9.0` | `v0.9.1`, `v0.10.0`, … |
| next version after a breaking change | minor, while < 1.0.0 |
unchanged |
| who decides a release goes out | a maintainer merging | a maintainer
merging the release PR |

`include-component-in-tag: false` keeps the bare `vX.Y.Z` shape rather
than `spec/vX.Y.Z`, and `.release-please-manifest.json` starts at
`0.9.0` so numbering continues rather than restarting. `release-type:
simple` because the root `package.json` is `private: true` and carries
no version of its own; `simple` tracks the version in `version.txt`,
which is why that file is added here.

## Scope: the specification package only

One package, `.`, tagged `vX.Y.Z` as it always has been.

The conformance assets under `specification/assets/provider-tck` need
their own tags too — a Go consumer cannot name a version without one —
but that configuration belongs beside the assets, so it is added in
[#423](#423) along with the
files it describes. This PR stays the general setup and can merge on its
own.

## What does change, and needs a decision

**Release notes become generated from conventional commits.** v0.9.0's
notes were written by hand, including the `⚠️ This release contains
breaking changes` callout linking #280, #306 and #360. Anything beyond
the commit subjects now has to be added to the release pull request
before it is merged.

If the TSC would rather keep the old shape, `changelog-sections` can be
tuned in a follow-up — the defaults are left here so the first release
is easy to eyeball.

## What to expect on merge

release-please runs on push to `main` and should open a release pull
request proposing **v0.9.1**; the non-chore commits since v0.9.0 are
#416, #419, #429 and #408, all `fix:` or `docs:`. Nothing is tagged
until that pull request is merged, so the first run is reviewable before
it has any effect.

The action configuration is the shape v5 actually reads: `command` and
`default-branch` are not v5 inputs, `target-branch` is, and `signoff` is
a configuration-file option rather than an action input — which matters
because this repository enforces DCO on the bot's own commits.

---------

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com>