Summary
Define the deprecation channel for all four frozen surfaces, document it in
RELEASING.md, implement the runtime warning mechanism, and exercise it once
before v1.0.0.
Why v1
ROADMAP §2
shippable artifact:
Deprecation channel documented in RELEASING.md.
and demonstrable signal:
Deprecation channel exercised at least once in practice before tagging v1.0.0.
The second one is a scheduling constraint, not just a doc task — a real
deprecation has to ship in a pre-v1.0.0 release with a working warning.
Current state
RELEASING.md §Versioning is three bullets: semver, RC naming, and "breaking
changes increment MAJOR." There is no statement of what "breaking" means per
surface, no notice period, and no mechanism for warning a user before removal.
Scope
1. Policy (RELEASING.md). For each of CLI, REST, Go SDK, and bundle/schemas:
what counts as breaking, what counts as additive, the minimum notice period in
releases or calendar time, and where deprecations are announced.
2. Mechanism, per surface:
- CLI — deprecated flags/commands still work but emit a warning to stderr
naming the replacement and the removal release. Must respect NO_COLOR and
the existing logger conventions.
- REST —
Deprecation and Sunset response headers (RFC 8594) on
deprecated endpoints, plus deprecated: true in api/aicr/v1/server.yaml.
- Go SDK —
// Deprecated: godoc markers, which staticcheck surfaces to
consumers automatically.
- Schemas/bundle — deprecated fields marked in the generated JSON Schema
and honored-but-warned by the loader.
3. Announcement surface — a ## Deprecations section in release notes and
a durable page under docs/user/.
4. Exercise it once — pick a genuine deprecation and ship it through the
full channel pre-v1.0.0. The /v1 vs /v2 REST path families (#2112) are a
natural candidate if /v1/* is being retired.
Acceptance criteria
Related
#2111, #2112, #2113 (the gates that will point users at this channel when they
trip), #2114 (apiVersion promotion is itself a candidate first exercise).
Summary
Define the deprecation channel for all four frozen surfaces, document it in
RELEASING.md, implement the runtime warning mechanism, and exercise it oncebefore
v1.0.0.Why v1
ROADMAP §2
shippable artifact:
and demonstrable signal:
The second one is a scheduling constraint, not just a doc task — a real
deprecation has to ship in a pre-
v1.0.0release with a working warning.Current state
RELEASING.md§Versioning is three bullets: semver, RC naming, and "breakingchanges increment MAJOR." There is no statement of what "breaking" means per
surface, no notice period, and no mechanism for warning a user before removal.
Scope
1. Policy (
RELEASING.md). For each of CLI, REST, Go SDK, and bundle/schemas:what counts as breaking, what counts as additive, the minimum notice period in
releases or calendar time, and where deprecations are announced.
2. Mechanism, per surface:
naming the replacement and the removal release. Must respect
NO_COLORandthe existing logger conventions.
DeprecationandSunsetresponse headers (RFC 8594) ondeprecated endpoints, plus
deprecated: trueinapi/aicr/v1/server.yaml.// Deprecated:godoc markers, whichstaticchecksurfaces toconsumers automatically.
and honored-but-warned by the loader.
3. Announcement surface — a
## Deprecationssection in release notes anda durable page under
docs/user/.4. Exercise it once — pick a genuine deprecation and ship it through the
full channel pre-
v1.0.0. The/v1vs/v2REST path families (#2112) are anatural candidate if
/v1/*is being retired.Acceptance criteria
RELEASING.mdDeprecation/Sunsetheaders +deprecated: truein the OpenAPI spec// Deprecated:convention documented forpkg/client/v1docs/user/v1.0.0Related
#2111, #2112, #2113 (the gates that will point users at this channel when they
trip), #2114 (apiVersion promotion is itself a candidate first exercise).