[{"data":1,"prerenderedAt":76},["ShallowReactive",2],{"term-b\u002Fbreaking-change":3,"related-b\u002Fbreaking-change":60},{"id":4,"title":5,"acronym":6,"body":7,"category":40,"description":41,"difficulty":42,"extension":43,"letter":44,"meta":45,"navigation":46,"path":47,"related":48,"seo":54,"sitemap":55,"stem":58,"subcategory":6,"__hash__":59},"terms\u002Fterms\u002Fb\u002Fbreaking-change.md","Breaking Change",null,{"type":8,"value":9,"toc":33},"minimark",[10,15,19,23,26,30],[11,12,14],"h2",{"id":13},"eli5-the-vibe-check","ELI5 — The Vibe Check",[16,17,18],"p",{},"A Breaking Change is a modification to your API or library that will BREAK existing code that uses it. If you rename a function, remove a parameter, or change a response format, anyone using the old version will need to update their code. Breaking changes require a major version bump and a big warning in the changelog.",[11,20,22],{"id":21},"real-talk","Real Talk",[16,24,25],{},"A breaking change (breaking API change) is a modification that is not backward-compatible, requiring consumers to update their code to continue working. In SemVer, breaking changes must increment the MAJOR version. Examples include removing endpoints, changing required parameter types, or modifying response schemas.",[11,27,29],{"id":28},"when-youll-hear-this","When You'll Hear This",[16,31,32],{},"\"That's a breaking change — bump the major version and document it clearly.\" \u002F \"We try to avoid breaking changes in our public API — they cause pain for all our integrators.\"",{"title":34,"searchDepth":35,"depth":35,"links":36},"",2,[37,38,39],{"id":13,"depth":35,"text":14},{"id":21,"depth":35,"text":22},{"id":28,"depth":35,"text":29},"cicd","A Breaking Change is a modification to your API or library that will BREAK existing code that uses it.","beginner","md","b",{},true,"\u002Fterms\u002Fb\u002Fbreaking-change",[49,50,51,52,53],"Semantic Versioning","SemVer","Changelog","Release","API",{"title":5,"description":41},{"changefreq":56,"priority":57},"weekly",0.7,"terms\u002Fb\u002Fbreaking-change","iOM8CUQ92Fro0OEEYDfZEAjIlFhTB0q7vYVofZdeODs",[61,66,69,72],{"title":53,"path":62,"acronym":63,"category":64,"difficulty":42,"description":65},"\u002Fterms\u002Fa\u002Fapi","Application Programming Interface","backend","An API is like a menu at a restaurant. The kitchen (server) can do a bunch of things, but you can only order what's on the menu.",{"title":51,"path":67,"acronym":6,"category":40,"difficulty":42,"description":68},"\u002Fterms\u002Fc\u002Fchangelog","A Changelog is a file (usually CHANGELOG.md) that records what changed in each version of your software.",{"title":52,"path":70,"acronym":6,"category":40,"difficulty":42,"description":71},"\u002Fterms\u002Fr\u002Frelease","A release is an official versioned snapshot of your software that you hand to the world.",{"title":49,"path":73,"acronym":50,"category":74,"difficulty":42,"description":75},"\u002Fterms\u002Fs\u002Fsemantic-versioning","general","Semantic versioning uses three numbers — MAJOR.MINOR.PATCH — where each number means something. PATCH (1.0.1) = bug fix. MINOR (1.1.",1776518261200]