| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
The Branching Model bullets and the "Breaking Changes" section were written while v2 was still being assembled, and read as instructions for making a breaking change: be intentional about it, then write it up in docs/migration.md. With 2.x released that nudges the wrong way. State the 2.x compatibility contract in one bullet, mark docs/migration.md as closed to new entries, and drop the Breaking Changes section, which only existed to describe how to add to that file. No-Verification-Needed: contributor-guidance doc only
| Back | FazBrowse Home | New Git URL |
Rewords 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 nudge an agent toward "breaking public API is fine as long as it's written up in the migration guide", and treat docs/migration.md as a live document to append to.
This PR states the 2.x compatibility contract in one bullet (changes to existing public API are an explicit maintainer decision and generally avoided), marks docs/migration.md as the finished v1 → v2 record that's closed to new entries, and drops the ## Breaking Changes section, which only existed to describe how to add to that file.
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.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.