Should we look to upgrade the version of jQuery bundled with the framework for 3.2?

Breaking SilverStripe modules isn't perhaps a bad thing (apart from work to update to 3.2 compatibility, I think many modules might need to do work anyway given the massive ORM rewrite tractorcow wrote and was merged in by simon_w recently.

Anyone else care to comment as to what is likely to break with this?

Is there a "safe" version of jquery we could consider or shall we go for it and grab latest? What is the lifecycle of jquery these days?

Upgrading to 1.8 should be fairly trivial as it didn't introduce many breaking changes (it only removed obscure or undocumented features).

However 1.9 was quite a big change, in particular removing .live(), which I'm sure lots of SS plugins used for the CMS. see http://jquery.com/upgrade-guide/1.9/

If we are prepared to move past that then going onwards to 1.11 should work fairly painlessly.

There's always the jQuery Migrate plugin (https://github.com/jquery/jquery-migrate/) to help the move, too.

Good info @danielhensby :)

using .live() has been considered bad practice for long before 1.8, though and jQuery had given a lot of warning to people to use delegation through .on() instead...

However, we can see @unclecheese is still quite a fan of it (https://github.com/unclecheese/KickAssets/blob/master/javascript/kickassets.js)

Yes, I am a fan. That is, if the present tense refers to 2011 when that code was written for SS 2.4.

In my experience with event binding and delegation in 3.x, jQuery core methods are not your friend. You're really best off going through entwine. Will Entwine play nicely with a newer version of jQuery? I wouldn't be surprised if 1.9 breaks it. :(

Lots of modules CMS modules out there, e.g. form fields, are depending on jQuery 1.7, and a 1.9 upgrade will most certainly hose them.

How hard would it be to write a script that detected the use of live()? even just searching JS files for a regex similar to ".live(" would get you 80% of the items.

We could potentially look at running a long process to download modules, run the detection script, and filter down to a list of problematic modules. Then, maybe, we could email the maintainers?

The other thing that I would say about upgrading jQuery is that it might be a good time to switch to a composer package: https://packagist.org/packages/components/jquery

IMO this is a 3.2 change, i.e., current master.

I would recommend having a standard rule e.g. with every 3.2 to 3.4 or 3.7 to 3.8 we upgrade to the latest version of Jquery... Of course we can break that rule, but it would be great just to have a standard answer to this... advantages are:

(a) you can plan in advance
(b) we dont have to discuss it
(c) we ensure to stay close to the latest jQuery version

I am not sure how I feel about using composer for frontend dependencies.
And if it wouldn't be better to introduce some frontend dependencies manager?
(I see the problem of having yet another tool, but composer is not really designed for frontend and most frontend projects will not use composer)

also, on the subject of updating jquery, since we are already breaking a lot with 3.2, has anyone considered just updating to jquery 2.x?
(don't have on my mind if we still support IE8, but if we do, I would vote to drop that anyway)