[jerf]

I would suggest the release notes are a better link target: http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/

Developers can figure out how to download it if they are interested.

[bryanlarsen]

That was submitted yesterday and flagged as a dupe. https://news.ycombinator.com/item?id=11871658

[dang]

It was a dupe, as is the current post. I explained this at https://news.ycombinator.com/item?id=11872457.

Perhaps we should stop having major discussions when things come out as release candidates, so that we can have the major discussion on actual release? I don't know. Trying to make it work that way might just cause more problems.

[forgotpwtomain]

I for one missed the rc1 post appearing here - as I think a number of other people did too judging from the comments and the interest gauged from the upvotes. Would a potential consideration be to attach the release-candidate discussion threads into the main release discussion, or would that cause more confusion than it's worth?

[captn3m0]

I think that makes sense. All rc announcements have the same issue.

[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.