Background in #3166985: [Proposal] provide supported / recommended jQuery versions for Security coverage → .
We're now preparing for a stable release from the 7.x-4.x branch which will then be the only supported release for the module.
Remaining tasks (not necessarily in priority order):
Overall, adding test coverage is great (and has already proved useful when e.g. removing old versions of libraries). However, achieving anything close to complete test coverage is probably unlikely and does not need to block a release.
I'd initially planned to retain all of the old library versions but specifically mark a small subset of versions as "supported".
On reflection, I think it's better to strip out as much as possible - this practically means removing anything that was not going to be marked as supported.
Any sites that really need to restore old / unsupported versions can do so via the Custom path functionality either via a CDN or local copies. Ideally I'd hope most sites can use one of the small number of "supported" versions though.
jQuery UI is an interesting problem. As per recent comments in #2197253: Update jQuery UI to the latest version (1.13) → around a year ago the project somewhat unexpectedly issued a new release that fixed some security issues, and there was some suggestion that this would be the "final release". However, there have been at least two more point releases since then.
It's great that the project is still being supported, but what we're trying to achieve with jQuery Update is decoupling the Drupal module from upstream releases.
So we need to make a decision on jQuery UI as to whether we add any newer release (I think we should not) and whether we remove any of the older versions.
The initial plan to keep all the old versions in the module but mark a chosen few releases as "supported" meant we added some functionality to requirement hook which shows warnings on the status report if an "unsupported" configuration is detected.
If we remove all but the supported versions, these warnings are redundant. Except perhaps in the case of the newest releases where we currently have a "phone home" functionality to check whether e.g. jQuery 3.6.0 is the latest release and should therefore be considered "supported".
I think if we're removing all the old versions other than the last releases from the jQuery 1.x and 2.x branch we could remove the "supported versions" requirements checks / warnings. We could possibly retain some optional functionality where the module can phone home (perhaps only during the requirement hook) to check for more recent releases of e.g. jQuery, jQuery UI and jQuery Migrate. This could be info-only and not generate a warning (the module's not smart enough to know if new releases include security fixes, for example).
In general the approach is to try to stop providing old outdated versions of libraries and allow sites to easily keep up-to-date with new releases of libraries.
The concept of a "supported" version is a little fuzzy anyway as we don't know for sure how much longer the Drupal Security Team will be providing security coverage for D7 and D7 contrib projects (see https://www.drupal.org/psa-2022-02-23 → ).
Once the remaining wrinkles outlined here are ironed out, we can proceed with the stable release.
Fixed
4.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Closing this as fixed; just released 7.x-4.1 with some very minor bug fixes.
We're ready to mark the 7.x-2.x branch as unsupported now.
I aim to do that early next week so as not to ruin anybody's weekend :)
Automatically closed - issue fixed for 2 weeks with no activity.