docs(issues): add specification for #2183 - #2187
Open
da2ce7 wants to merge 5 commits into
Open
Conversation
The workspace floor has only ever been discovered from the dependency tree: 1.85 came from edition 2024 and 1.88 from a transitive requirement, so the compatibility promise moves on a third party's schedule and is re-argued at every raise. The draft proposes computing rust-version from the calendar instead, as the newest stable release at least one year old, and enforcing it with a CI job that reads the manifest, which the repository currently lacks entirely. One computed floor also answers the application and the future extracted libraries with the same number, superseding the per-class split deferred by issue 1787.
The reviewed draft now has a GitHub issue, so the specification moves from the drafts folder to `docs/issues/open/` under its assigned number, and its frontmatter, heading, workflow checkpoints and progress log record that number together with the spec-only delivery branch. The Computation section now states that the 1.89.0 and 1.90.0 publication dates were verified against the upstream Rust release history rather than carried over from a sibling repository unchecked, while keeping the requirement that the implementer recomputes the pin on the day the change lands.
Commit signing is a repository-wide invariant enforced by the merge tool and the contributor workflow. Restating it inside one task's commit policy is redundant and reads as if signing were optional for work outside that plan.
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Pull request overview
Adds a folder-style issue specification documenting the proposed calendar-based MSRV policy for #2183 (no implementation changes).
Changes:
- Add a new
docs/issues/open/.../ISSUE.mdspec describing the MSRV policy, ADR/workflow updates, and acceptance criteria. - Document computed MSRV rule (one-year-old stable Rust), enforcement approach, and recomputation procedure.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The T3 row of the implementation plan carried the pin extraction command inline in a table cell, where the pipe had to be written as an escaped pipe so the cell would not split. GitHub's renderer consumes that escape, so the command reads correctly on the pull request page, but the raw markdown does not: an implementer working from the file in the tree copies a backslash into the shell, where it stops the pipe from being a pipe and passes head and its argument to sed instead. These specifications are read as raw markdown by whoever implements them, so the source form is the one that has to be correct. The command moves into a fenced block under Job shape, where the pipe needs no escape and the line can be copied verbatim into the workflow step, and the T3 row points at it. The note added alongside states why the anchored pattern matches only the workspace declaration, which is the property manual scenario M4 already verifies.
Records both review threads with their decision and the evidence behind it: the doubled-pipe report is declined, because the pattern does not occur in the file and the renderer produces no blank column for either table it names; the escaped-pipe report is accepted for the source form, which is what an implementer reads, and the command was relocated into a fenced block. Both threads carry a reply before being resolved, and a re-fetch after the round reports two threads and none unresolved.
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
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.
Related to #2183
Summary
This pull request adds the reviewed specification for issue #2183 and contains no implementation, so it does not resolve the issue.
The specification proposes replacing the workspace's dependency-driven Minimum Supported Rust Version with a computed one:
rust-versionbecomes the newest stable Rust release that was published at least one year before the day the pin is computed. The floor is then a function of the calendar and the Rust release history alone, never of a dependency requirement, a feature wish, or a reviewer preference, and it only ever rises. The rule is to be recorded as a repository-wide ADR indocs/adrs/, enforced by a new job in.github/workflows/testing.yamlthat reads the pin out ofCargo.tomlrather than duplicating the literal, and recomputed at the maintenance moments the policy names, which the specification places inside theupdate-dependenciesskill and the release process so the recomputation happens rather than depending on someone remembering the ADR.The specification also records why the calendar rule supersedes the split policy that issue #1787 deferred to the
bittorrent-*extraction: one computed number is already correct for both crate classes, so an extracted library carries the rule rather than a number and the singlerust-version.workspace = trueinheritance across all 25 members stays intact.The computed pin and the recompute rule
Applied on 2026-09-09 the rule yields 1.89: Rust 1.89.0 was published on 2025-08-07 and is the newest release at least one year old, while 1.90.0 was published on 2025-09-18 and is not yet. Those two publication dates were verified against the GitHub releases API for
rust-lang/ruston 2026-09-09, which reports 1.89.0 at 2025-08-07T10:55:11Z and 1.90.0 at 2025-09-18T20:02:56Z.The value in the specification is not the value to apply. It is a function of the implementation date, and from 2026-09-18 the same rule yields 1.90. The implementer recomputes on the day the change lands and records the computation in the progress log; acceptance criterion AC2 fails a value copied from the specification's table without recomputation.
Files touched
Only
docs/issues/. The branch addsdocs/issues/open/2183-adopt-calendar-msrv-policy/ISSUE.mdand no other file, so no source, test, workflow, or manifest is changed here.Validation performed
linter allpasses with exit code0at the branch tip, covering markdown, local Markdown links and fragments via lychee, YAML, TOML, cspell, clippy, rustfmt, and shellcheck.The full pre-commit gate
./contrib/dev-tools/git/hooks/pre-commit.shpasses with exit code0, all six steps green: dictionary formatting, unused dependencies viacargo machete --with-metadata, workspace layer boundary bans viacargo deny check bans, all linters, the Containerfile hadolint check, and the workspace documentation tests.Every relative link in the moved document was resolved from its new location and verified to exist. The folder moved from
docs/issues/drafts/<name>/todocs/issues/open/<name>/, which is the same directory depth, so the../../closed/and../../../adrs/targets are unchanged and still resolve; lychee confirms this independently.