I can’t speak for the themes or RapidWeaver, but I can let you know about Stacks – it’s probably a lot more complicated than you bargained for.
So here’s the short version: Stacks tries to use the latest version – but will use older versions when stacks on the page need older versions. Stacks v4.1 will come with jQuery v3.5
Many of Versions from Many Places
By default Stacks doesn’t include any libraries like jQuery, but since many stacks require jQuery, and have different version requirements themselves, Stacks manages the jQuery version shared by for the whole page.
Stacks uses a flexible heuristic to deliver the most recent jQuery version that is compatible with every stack on the page.
Stacks can also let you choose whether you’d like to deliver jQuery from your own server or use a CDN – which, in the case of jQuery, will be the Google CDN.
Closures are Good Things™
JS gives web developers a lot of power, it can be easy to shoot off your own toes when you’re just getting started. Think of our nicely set up closure as bullet-proof boots for each stack.
The Stacks API gives each stack the ability to define a minimum and maximum compatible version of jQuery that they require – or just one, or neither.
When just one stack requests jQuery and defines no mins/maxes the version delivered will be the latest at the time of the major version of Stacks. For Stacks 4.0 that was jQuery v3.1.1.
Stacks 4.1 is coming soon-ish – and when it goes out it should include the latest version of jQuery that’s available on the Google CDN (we only include a version if it’s also made it through the Google CDN release process – which tends to skip some of the buggier releases).
How to Get jQuery v3.5
If you have a page that’s including v3.1.1 then it will likely just update itself to v3.5.x when Stacks v4.1 is released. So – basically do nothing.
But if you page is currently using something a bit older to than v3.1.1, then it’s probably because there a stack on that page that is asking for an older version. This happens when they set the “maxVersion”
But wait there’s more… and unfortunately it’s not pretty. jQuery v2 included many substantial breaking changes. This meant our nicely laid out plan to keep everyone up to date suddenly broke very badly. I suspect if you search this forum back about 8 years or so you’ll find out what a catastrophe it was. For that reason, we’re a bit more careful about how we update between v1 -> v2 and v2 -> v3.
I’m not going to go into details here, but the gist is that we want those large updates to be opt-in for developers. So if you have some very old stacks that haven’t been update in many years, then you might be getting held back to jQuery v1. The way forward is to upgrade that stack.
Which stack is holding me back?
It’s not generally listed anywhere for users to see (but it would be a nice feature request for the developer console I think). jQuery version handling gets pretty tricky when you’re ballancing the requirements for many stacks – it’s not something most users ever want to know about. But if you do want to know about it, then the stack developer that created the stack is a good source. Most stack developers have a good idea if they’re setting the max value low for a specific stack.
And if all else fails, you can use divide and conquer to delete stacks, then export the page (on a copy of the project, of course) until the jQuery version changes – then you can see how each stack’s contribution to the jQuery version soup.
If you’d like help in determining this, just let me know.