Problem description
Current release-plan.yaml validation (P-009, P-022, P-023) covers regex-level checks on individual fields. Combinations of fields can still pass these checks while being internally inconsistent — and the same content drives the release at pre-snapshot, so an inconsistency that slips through is no longer just a documentation issue.
Possible evolution
Add a class of cross-field consistency rules running both at PR-time on release-plan.yaml changes and at pre-snapshot on the active release plan.
Example case — target_api_status: public is valid only if either:
target_release_type is public, or- the
target_api_version was previously published in a public release (e.g. an unchanged stable base API in a cycle that only ships subscription changes).
A merged real-world instance of this inconsistency: WebRTC#140 sets target_api_status: public for a target_api_version that has not previously been published as public.
Further validation requirements welcome as comments on this issue before scoping. Please include the field combination, the failure mode it would catch, and — if known — a published release plan where it would have flagged a real issue.
Alternative solution
Renaming fields (e.g. target_api_version → target_api_base_version, target_api_status → next_api_release_status) so the "next release" semantics are self-evident. Out of scope here: that is a breaking schema change and would need to be handled as a major schema revision.
Additional context
Once the rule list stabilises in comments, scoping moves into the validation framework and a dedicated regression/r4.2-release-plan-validation branch with bogus-tag and exclusivity-violation fixtures.
Problem description
Current release-plan.yaml validation (P-009, P-022, P-023) covers regex-level checks on individual fields. Combinations of fields can still pass these checks while being internally inconsistent — and the same content drives the release at pre-snapshot, so an inconsistency that slips through is no longer just a documentation issue.
Possible evolution
Add a class of cross-field consistency rules running both at PR-time on release-plan.yaml changes and at pre-snapshot on the active release plan.
Example case —
target_api_status: publicis valid only if either:target_release_typeispublic, ortarget_api_versionwas previously published in a public release (e.g. an unchanged stable base API in a cycle that only ships subscription changes).A merged real-world instance of this inconsistency: WebRTC#140 sets
target_api_status: publicfor atarget_api_versionthat has not previously been published as public.Further validation requirements welcome as comments on this issue before scoping. Please include the field combination, the failure mode it would catch, and — if known — a published release plan where it would have flagged a real issue.
Alternative solution
Renaming fields (e.g.
target_api_version→target_api_base_version,target_api_status→next_api_release_status) so the "next release" semantics are self-evident. Out of scope here: that is a breaking schema change and would need to be handled as a major schema revision.Additional context
Once the rule list stabilises in comments, scoping moves into the validation framework and a dedicated
regression/r4.2-release-plan-validationbranch with bogus-tag and exclusivity-violation fixtures.