[lucb1e]

> "We set out to create a slimmer, faster version of jQuery (with backwards compatibility in mind)."

Wait, isn't the whole point of a major version bump that it breaks backwards compatibility?

Later on it says there are a few breaking changes, but not many apparently. Which in general is a good thing, but focusing on keeping compatibility through a major version bump seems silly.

[cstejerean]

It's not that silly. Yes, a major version bump allows you to break backwards compatibility in some ways. But if the break is too severe you run the risk of preventing a large percentage of the user base from upgrading. So it's still a good idea to carefully consider exactly where to introduce breaking changes and to try and keep the burden of upgrading proportional to the benefits offered by the upgrade.

[bradly]

Backwards compatibility is still quite important in major version releases. Just look at Angular 1 to 2, Rails 2.3 to 3, and Python 2 to 3 to see examples of this.

[dceddia]

I'd say (and probably this is what you meant) that those are examples of what happens when backwards compatibility is broken - the community gets fragmented, finding answers on StackOverflow gets more difficult, lots of helpful blogs/articles/videos are now useless, etc.

[omni]

> focusing on keeping compatibility through a major version bump seems silly.

I'd offer the Python 3 fiasco as a counterexample.

[Aldo_MX]

> Yes, there are a few “breaking changes” that justified the major version bump, but we’re hopeful the breakage doesn’t actually affect that many people.

BC is "desirable", not "required", if breaking compatibility makes sense to develop a major improvement, then do it.

[wvenable]

A some point if you break too much compatibility, it just becomes a completely different product instead a new version of an existing product.

[rhizome]

Wait, isn't the whole point of a major version bump that it breaks backwards compatibility?

It's not a requirement.

P.S. HN users sure are big on silent downvotes these days.