chore: release - #174
Merged
Merged
chore: release#174
Conversation
github-actions
Bot
force-pushed
the
release-plz-2026-09-23T05-18-56Z
branch
4 times, most recently
from
September 23, 2026 06:25
1358e3a to
9256e66
Compare
github-actions
Bot
force-pushed
the
release-plz-2026-09-23T05-18-56Z
branch
from
September 23, 2026 06:54
9256e66 to
8be43b2
Compare
release-plz walks the mainline, so on a repo that merges PRs with merge commits it sees only "Merge pull request #N from …" — unconventional, and filtered out — never the `feat`/`fix`/`perf` commits inside the branches. Both release sections came out empty as a result. These are what git-cliff produces from the full range (`ontogen-v0.7.0..main`, `ontogen-core-v0.5.0..main`), which is the same content release-plz would have written had the commits been on the mainline. ontogen-core's breaking changes are the two cargo-semver-checks reported on the release PR. Switching the repo to squash merges puts one conventional commit per PR on the mainline and stops this recurring; the empty 0.6.2, 0.6.3, 0.6.4 and 0.6.7 sections are the same fault.
sksizer
added a commit
that referenced
this pull request
Sep 26, 2026
…y until 1.0 (#176) Writes down a rule that has been decided case-by-case until now, and the corollary that gives it teeth. ## The rule **Until 1.0** — API design trumps backwards compatibility. A cleaner surface justifies a break. No shims, no transitional aliases, no `foo2()` beside `foo()`. **From 1.0** — the ability to evolve the API is itself part of the API. A surface that cannot absorb a new field, variant or mode without a major bump is not finished, however clean it looks. ## Why they are one decision and not two Installing an evolvability mechanism is *itself* a breaking change. Per the Rust reference, a `#[non_exhaustive]` type "cannot be constructed with a StructExpression (including with functional update syntax)" — so adding it breaks every consumer literal *and* every `..base` update. It can therefore only be fitted while breaking is free. **Phase 2 is affordable only if phase 1 is spent installing the hinges.** The pre-1.0 window is not just for getting the shape right; it is for fitting the joints the shape will later need to bend at. ## What forced the question Two forces had been pulling against each other with nothing to arbitrate: - **Semver tooling pushes toward preservation.** cargo-semver-checks flagged two *additive* improvements on #174 — `constructible_struct_adds_field` for `EntityDef.doc`/`FieldDef.doc`, `enum_variant_added` for `CodegenError::Docs`. Every such flag creates quiet pressure to contort the design to keep the check green. - **Design review pushes toward re-cutting.** The pagination review found the feature declared in four config structs, two of which can silently diverge. Later exploration widened it: `ServersConfig` and `ClientsConfig` duplicate **twelve** fields, and both stages independently scan their own copy of `api_dir`. Pagination is one instance of a bug class with twelve. With no rule, the decision defaults to whichever is locally cheaper — always preservation, since it requires no work. That default is how the divergence accreted. Nobody chose it; it is the residue of never having chosen. ## Notable contents - A **hinge table** — the six mechanisms to install before 1.0. Three were already applied in the pagination design before this ADR named them (open-string `mode`, the nested `list` capability object, reserved `order_by`/`order` slots), which is the evidence the instinct was sound. - **`semver_check = true` explicitly stays.** The rule is "do not *avoid* breaks," not "do not *detect* them" — the check drives the version bump rather than a redesign. Dropping it is listed as a rejected alternative because it is the tempting misreading. - **Blast-radius asymmetry is named.** A build-time break is caught at compile time; a generated-protocol break fails at runtime for already-deployed clients. Same freedom, different consequence — so protocol breaks get flagged in the changelog as deploy-ordering hazards. Live immediately: 0.8.0 changes the list envelope. - An **owed obligation**: a pre-1.0 evolvability sweep, deadlined at 1.0. Its failure mode is silent expiry, not visible overdue-ness. ## Also Replaces the stale "None written yet" line in the ADR README with an index, and records 0002 as reserved by T-66TG per the numbering convention. ## Review focus The decision itself, not the prose. Two calls made without explicit sign-off, both easy to reverse: extending the rule to the generated wire protocol (with the asymmetry called out rather than a separate policy), and leaving the sweep untracked pending a decision on where it should live.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 New release
ontogen-core: 0.5.0 -> 0.6.0 (⚠ API breaking changes)ontogen: 0.7.0 -> 0.7.1 (✓ API compatible changes)⚠
ontogen-corebreaking changesChangelog
This PR was generated with release-plz.