Goal
Define a lightweight release stabilization policy that matches Base's change velocity and single-maintainer concentration.
Background
Base has strong automated validation but a very rapid commit and release cadence, with most changes and reviews coming from one maintainer. CI substantially reduces ordinary regression risk; it does not replace compatibility bake time or independent judgment for high-impact boundaries.
#1600 tracks publishing v1.7.0. This issue defines the durable policy for when future releases need a candidate, stabilization period, compatibility evidence, or explicit review waiver.
Scope
- Define which releases require an RC or beta and which patch releases may proceed directly.
- Set minimum compatibility and upgrade checks for CLI, manifest, packaged, macOS, and supported Linux paths.
- Define a proportionate stabilization or bake expectation based on release risk.
- Require independent review for designated high-impact changes where available, with an explicit documented waiver when it is not.
- Define urgent security/patch exceptions.
- Integrate the policy with
basectl release check, release documentation, and milestone reconciliation where appropriate.
Acceptance Criteria
- Release types have clear candidate, bake, validation, and review expectations.
- The policy does not block urgent patches or require unavailable reviewers without an explicit waiver path.
- High-impact manifest, trust, installer, and compatibility changes receive proportionate review.
- Release checklists and tooling reference the same policy.
- The next qualifying release can record objective compliance evidence.
Validation
- Rehearse the policy against v1.7.0 or the next eligible release without changing published history.
- Verify release docs, checklist, and tool output remain consistent.
- Add focused release-policy tests if executable gates change.
git diff --check.
Non-Goals
- Do not require a large governance organization before contributors exist.
- Do not replace automated CI with manual approval.
- Do not impose the same ceremony on urgent patches and major compatibility changes.
Project Fields
- Status: Backlog
- Priority: P2
- Size: M
- Area: Packaging
- Initiative: Contract Hardening
Agent Assignment
Human first. This is a release-risk policy decision; tooling follow-ups can be agent-ready once the policy is agreed.
Goal
Define a lightweight release stabilization policy that matches Base's change velocity and single-maintainer concentration.
Background
Base has strong automated validation but a very rapid commit and release cadence, with most changes and reviews coming from one maintainer. CI substantially reduces ordinary regression risk; it does not replace compatibility bake time or independent judgment for high-impact boundaries.
#1600 tracks publishing v1.7.0. This issue defines the durable policy for when future releases need a candidate, stabilization period, compatibility evidence, or explicit review waiver.
Scope
basectl release check, release documentation, and milestone reconciliation where appropriate.Acceptance Criteria
Validation
git diff --check.Non-Goals
Project Fields
Agent Assignment
Human first. This is a release-risk policy decision; tooling follow-ups can be agent-ready once the policy is agreed.