docs(engineering): road-to-1.0.0 release checklist#98
Merged
Conversation
Companion to the existing Stability commitments page. The stability page describes what 1.0 commits us to; this new page describes the work needed *before* cutting 1.0 so the commitment is defensible. Structured as a four-week sequence of small PRs: 1. API surface freeze — drop `filters` / `max_iterations` reserved-but-ignored kwargs, deprecate `SolveResult.resolved`, audit Rust `pub` items, add `#[non_exhaustive]` to public enums, decide the `FamilyLoader` / `VersionRange` exposure question. 2. Correctness net — extract a ~200-package fixture corpus, wire `compare_resolves.py` into CI, scaffold property/fuzz tests on the solver, triage open issues (including #96). 3. Documentation — stability page lists exact public symbols (not qualitative claims), README drops experimental framing, changelog retitled. 4. Release — bump pins, verify wheel + crates publish flows, tag, announce. Explicit "what's not in 1.0" section to resist scope creep: the Rex evaluator, persistent caches, parallel solve_many, and daemon model are all 1.1+ work. The 1.0 bar isn't more features — it's confidence we can support what's already shipped. Closes the planning loop around the release. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
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
1 participant
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.
Summary
Adds
docs/content/docs/engineering/road-to-1.0.0.md— companionto the existing
Stability commitments
page. The stability page describes what 1.0 commits us to; this
new page describes the work needed before cutting 1.0 so the
commitment is defensible.
Docs-only. No code or API changes.
What's in the doc
Structured as a four-week sequence of small PRs:
filters/max_iterationsreserved kwargs, deprecateSolveResult.resolved, audit Rustpubitems, add#[non_exhaustive]to public enums, decideFamilyLoader/VersionRangeexposurecompare_resolves.pyinto CI, scaffold property/fuzz tests, triage open issues (#96 in particular)[1.0.0] — <date>Plus an explicit "What's not in 1.0" section to resist scope
creep: the Rex evaluator, persistent caches, parallel
solve_many, and daemon model are all 1.1+ work. The 1.0 barisn't more features — it's confidence we can support what's
already shipped.
Sign-off conditions at the end list the 6 must-be-true items
before tagging. If any aren't, ship another rc instead.
Test plan
references go to the existing
stabilitypage which is onmain)🤖 Generated with Claude Code