Close the door on breaking changes in AGENTS.md - #3286
Draft
maxisbey wants to merge 1 commit into
Draft
Conversation
The Branching Model bullets and the "Breaking Changes" section were written while v2 was still being assembled, and read as a workflow for making breaking changes: be intentional, then document it in docs/migration.md. Now that 2.x is the released stable line, the guidance an agent should find is "don't, and escalate if you think you must". Replace the two bullets with the 2.x compatibility contract and mark docs/migration.md as closed to new entries, and replace the Breaking Changes section with an API Stability section that says the same thing at the point an agent goes looking for permission. No-Verification-Needed: contributor-guidance doc only
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.
Rewrites the two places in
AGENTS.mdthat still framed breaking changes as a documented workflow, now that 2.x is the released stable line.Motivation and Context
The Branching Model bullets ("removing or replacing an API must be intentional… changes that break code written against v1 must be documented in
docs/migration.md") and the## Breaking Changessection were written while v2 was being assembled. Read today, they tell an agent that breaking public API is fine as long as it's written up in the migration guide, and thatdocs/migration.mdis a live document to append to.Neither is true anymore. The 2.x public surface is a compatibility contract, and the migration guide is the finished v1 → v2 record.
This PR:
docs/migration.mdas closed to new entries (corrections and clarity edits still welcome).## Breaking Changeswith## API Stability, so the section an agent lands on when looking for permission says "no" instead of "here's how". It carves out fixes that bring behaviour in line with what the docstring or spec already says, with a note to call out the delta in the PR description.Everything else that mentions v2 (
mainis stable,v1.xis maintenance, README documents v2, the conformance-suite rule) already describes the released state and is untouched.How Has This Been Tested?
pre-commit run --files AGENTS.md(markdownlint) passes. No code changes.Breaking Changes
None.
Types of changes
Checklist
Additional context
CONTRIBUTING.mdstill tells human contributors thatmaintakes "New APIs, refactors" with no stability caveat; left for a follow-up so this stays scoped to agent guidance.