ops(release): bump the minor version for a feature

[disconsented]

The first release PR that the fixed workflow opened (#72) proposed 0.2.1. It should be 0.3.0.

Why it proposed a patch

Cargo semver reads the minor of a 0.x version as its major. A feature on 1.4.0 moves the minor to 1.5.0, but a feature on 0.2.0 moves only the patch, because 0.3.0 is reserved for a breaking change. release-plz follows that rule by default, so 208 commits with dozens of scoped feat entries still came out as 0.2.1.

features_always_increment_minor = true tells it to use the minor instead. Verified against the merged master with the real v0.2.0 tag:

INFO workshop-walker: next version is 0.3.0
* `workshop-walker`: 0.2.0 -> 0.3.0

The changelog section it writes is compare/v0.2.0...v0.3.0.

The warnings in the workflow log are not a fault

The run printed eleven of these:

WARN cannot read package metadata of workshop-walker in /tmp/.tmpaleExY/workshop-walker/
Caused by:
  this virtual manifest specifies a `dependencies` section, which is not allowed

release-plz walks master backwards from HEAD to the last release tag, checking each commit out and comparing the package against the released one. Eleven commits in that range carry a root Cargo.toml that cargo cannot parse. 7f7fbb7f build: Use workspaces is the first of them: it has [workspace], [workspace.package] and [dependencies], but no [package], which makes it a virtual manifest with a dependencies section. The run that hit them ends at 36f9a88 refactor(web): wire item, properties and query routes. The last warning is a different shape from the same era, where serde-hack inherits serde from a workspace.dependencies that did not exist yet.

That history is immutable and the warnings changed no result. They also stop on their own: once v0.3.0 is tagged, the walk covers v0.3.0..HEAD and never reaches those commits again.

Authorship

This branch is entirely the work of a stochastic parrot. Read it with that in mind.

🤖 Generated with Claude Code