Skip to content

Close the door on breaking changes in AGENTS.md - #3286

Draft
maxisbey wants to merge 1 commit into
mainfrom
docs/agents-api-stability
Draft

Close the door on breaking changes in AGENTS.md#3286
maxisbey wants to merge 1 commit into
mainfrom
docs/agents-api-stability

Conversation

@maxisbey

Copy link
Copy Markdown
Contributor

Rewrites the two places in AGENTS.md that 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 Changes section 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 that docs/migration.md is 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:

  • Replaces Branching Model bullets 2–3 with the 2.x contract: don't remove/rename/re-sign anything public, additions are permanent, and if a task seems to need a break, stop and raise it rather than deciding inside a PR.
  • Marks docs/migration.md as closed to new entries (corrections and clarity edits still welcome).
  • Replaces ## Breaking Changes with ## 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 (main is stable, v1.x is 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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

CONTRIBUTING.md still tells human contributors that main takes "New APIs, refactors" with no stability caveat; left for a follow-up so this stays scoped to agent guidance.

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant