Goal
Make release-invariant API checks follow the active release line without hidden local environment state.
Background
tests/release-invariants.sh hard-codes v2.0.0 as the default BASE_BASH_LIBS_RELEASE_REF, while the only documented release workflow promotes future API metadata for the next 2.x release. No CI workflow sets this override, and docs/release-process.md does not describe it. When a preview module is promoted to stable for a future release (for example, since: 2.1.0), the validation job will still compare that stable module against v2.0.0, where it cannot exist, unless a maintainer supplies an undocumented environment override. That makes release-preparation validation non-reproducible and risks either a blocked PR or an unreviewed CI configuration difference.
Scope
- Derive or explicitly configure the release reference used by
release-invariants from the active release contract and candidate version.
- Keep the current mainline check against the published GA reference when no release candidate is active.
- Document the CI/local command for release-preparation branches and make the workflow use the same value.
- Add a regression fixture covering promotion of a preview module into a future release tree.
Acceptance Criteria
- A release-preparation branch for the next supported 2.x version passes the same documented command locally and in CI without an undocumented environment variable.
- Ordinary mainline validation continues to enforce compatibility with the published GA release.
- The selected release ref and its provenance are visible in failure diagnostics.
Validation
./tests/validate.sh
- Focused
tests/release-invariants.sh/API-manifest tests for current-GA and future-release references.
- CI workflow review confirms no divergent hidden environment setup.
Non-Goals
- Changing the stable API compatibility policy.
- Publishing or retagging a release.
Project Fields
- Status: Backlog
- Priority: P2
- Area: CI
- Initiative: Adoption Polish
- Size: S
- Milestone: v2.1.0
Agent Assignment
Goal
Make release-invariant API checks follow the active release line without hidden local environment state.
Background
tests/release-invariants.shhard-codesv2.0.0as the defaultBASE_BASH_LIBS_RELEASE_REF, while the only documented release workflow promotes future API metadata for the next 2.x release. No CI workflow sets this override, anddocs/release-process.mddoes not describe it. When a preview module is promoted to stable for a future release (for example,since: 2.1.0), the validation job will still compare that stable module againstv2.0.0, where it cannot exist, unless a maintainer supplies an undocumented environment override. That makes release-preparation validation non-reproducible and risks either a blocked PR or an unreviewed CI configuration difference.Scope
release-invariantsfrom the active release contract and candidate version.Acceptance Criteria
Validation
./tests/validate.shtests/release-invariants.sh/API-manifest tests for current-GA and future-release references.Non-Goals
Project Fields
Agent Assignment