Breaking changes

Semantic Versioning has become a de-facto standard in the last few years, with several language ecosystems now relying on it to manage software upgrades. However, it is frequently misunderstood as a technical tool for making cold hard guarantees about code, rather than as a human tool for signalling intent and setting expectations.

Never is this more apparent than when we consider what a "breaking change" means. It's highly contextual: it depends on which language you're using, what your public interface is, what guarantees you've explicitly or implicitly made to users, how much software sits downstream of you, and so on. In this talk I'll explore several ways you can accidentally break other people's JavaScript apps, how to avoid them, and what to do when you can't.

OBJECTIVES

The aim here is to reframe our thinking about software compatibility and change management. Though there is certainly a role for formal tools like type systems in this problem, James believes it's primarily a human communication problem. It benefits from considering how code and its surrounding ecosystem conveys information to and from its users and factoring in the logistical and ergonomic problems of making changes at scale.

TARGET AUDIENCE

Though ostensibly targeting a JavaScript audience, the concepts in this talk apply to greater or lesser extent in other language ecosystems, and within any codebase of reasonable size. A basic understanding of JavaScript would be helpful but is not essential.