jQuery 3.0 to Adopt Semantic Versioning

Changes to jQuery introduced in 2013 have resulted in a strange beast. The popular library split into two roughly parallel paths of development: version 1.x continued to support older browsers (notably IE 6, 7, and 8), while version 2.x provided support for newer, compliant versions of browsers as well as mobile browsers. Yet the latest versions in each path have had largely compatible APIs, despite the different major and minor version numbers. The split has allowed the 2.x line of jQuery to be more streamlined by removing the need to carry along older browser backward compatibility code.

The result is that, as of November 2014, the current versions of jQuery are 1.11.1 and 2.1.1. Without researching the current state of the API in each, how would a developer know the compatibility of each version? A user can figure it out, and jquery.com does have the version numbers documented pretty well, but the use of multiple version numbers has created a bit of a mess. In essence, the jQuery developers have been trying to use version numbers to represent both browser version compatibility as well as API versioning—and it just hasn’t been working.

Last week, the jQuery Foundation—the non-profit organization that coordinates development of jQuery and various other open-source software projects—announced in a blog post, jQuery 3.0: The Next Generations, that all this was going to change. Going forward, jQuery will be split into jQuery and jQuery Compat, and these will be two separate libraries and packages. jQuery will be the successor to the jQuery 2.x line of development for evergreen browsers, defined as the latest browser version and the one previous. jQuery Compat will continue to include support for older versions of browsers, including IE 8, Opera 12, Safari 5, and later. It is likely that most websites will use jQuery Compat in order to support most of the browsers and versions used to access public websites. Just as before, jQuery will be more lightweight because it doesn't need to include browser backward compatibility code.

Both jQuery and jQuery Compat will be released as version 3.0, indicating that their APIs are compatible, so you’ll initially need to use either jquery-compat-3.0.0.js or jquery-3.0.0.js in webpages. With these changes, jQuery will make use of semantic versioning, which is usually just referred to as semver. The Semantic Versioning 2.0.0 spec summarizes semver like this:

Given a version number MAJOR.MINOR.PATCH, increment the:

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Practically speaking, semver gives developers a sense of the risk in moving to new versions of an API: patches and minor version updates should be close to risk-free, minor version updates will implement new features in a backward-compatible manner, and major version updates are likely to break existing code, presumably with the benefit of more and better features.

These changes are likely to be a bit painful for some; change always is. But the result will be a much cleaner versioning of jQuery, separating out support from browser versions and the API version as it evolves. I have to admit that I always felt cheated by limiting myself to jQuery 1.x, since 2.x just had to be better, right? I suppose that feeling comes from years of software vendors promoting new versions of software with higher version numbers, where newer HAD to be better.

Benjie Moss, in a post on DeveloperDrive about the announcement, made this observation:

"Why does this matter to developers? If you’ve been importing jQuery from Google you’re probably requesting a specific version, or at least a specific major version. If not, 3.0 will potentially break your site."

So how you handle updates to jQuery today will probably have to change, and it may affect code interactions with third-party scripts and packages.

One item of concern in the announcement of the changes comes to light in this statement: “Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions.” I suppose it is inevitable that someday, jQuery will stop keeping the Compat API in sync with the main API, but I’ve not found any discussion about how that may come about. Maybe that part of the future isn’t yet clear enough to know.

Overall, the jQuery Foundation is doing the right thing and the necessary thing to split browser compatibility from API versioning.

There’s no word yet on a release date for jquery-compat-3.0.0.js and jquery-3.0.0.js. Stay tuned.