Allow to load more than one version of jQuery at a time

The reason we only support one version at a time is that it is nearly impossible to predict which library will be loaded where.
If you could retrieve a list of pages which load version X and a list of pages which load version Y, then the problem would be lessened quite a bit.
But even then, you would come into cases, where you would have to load both libraries on the same page. But you can't do that, because that would lead to errors. So you would still have to implement some fallback mechanism in the dependants of the library. So the net win, seems to be near zero.

Love to hear your thoughts, though, I assume you have a different perspective. :)

Just looked at jQuery Multi.

Not to discredit your effort over there (it does seem like the cleanest possible way to do that), but it really feels like a hack.

There's ongoing discussion about how this would work ideally in Drupal core in #1400748: Proposal for unified namespace organization (at the bottom). My personal (as in not official Libraries API maintainer) position is that the ideal way would be for a contrib project à la jQuery Update to provide newer versions of core scripts that work with newer jQuery versions. Then dropping those in together with the new jQuery wouldn't break anything. Since the core scripts have to updated anyway for the next Drupal version (e.g. Drupal 8.x contains a newer version of jQuery than Drupal 7.0), the maintenance effort should be managable.

Hmm... I guess something like that could in theory be supported by http://drupal.org/project/jquery
Not sure yet, though, how the implementation should be. Because we really do not want to open that door for anybody else...

Hmm... I wonder if we had a Library class for all our business logic, that would allow jQuery to subclass that. That's of course highly theoretical, but it seems that would be the cleanest way to support such a custom logic?!

Note that for 7.x-3.x we will actually strive for a class-based architecture, so like I said in #5, I assume this would be possible. I'm leaving this open for now, but in the long run, this will probably handled by http://drupal.org/project/jquery

Docs reference:
"Only one version of a library can be installed per site", at
http://drupal.org/node/1342220

This limitation means that many sites will continue to find themselves in the eternal dilemma of balancing the ideal mix of functionality with the hard reality of available stable/secure versions (even when mixed versions are already supported in jquery itself), as there will always be various libraries with their Drupal counterparts in different state of development. This is even more of a battle when also the external libraries and the jquery library itself is in constant development, adding support for new things while removing some old features. This situation is not likely to end at all.

IMO, it is therefore important to help and encourage Drupal administrators to choose stable Drupal module versions as much as possible, which means supporting the common situation where various modules and versions comes with their own dependency on specific jquery versions.

If not, this indirectly causes more Drupal sites to take the risk of running less secure/stable -dev versions whenever the only real alternative is to skip crucial functionality alltogether (or be forced to choose modules that are less suitable for their needs).

Moving to the 3.x branch as a feature request, and upping the priority tentatively.

More suitable title (for a feature request)..(?)

For reference (2010 issue): #719896: Add a hook_libraries_info()
("The UI (Libraries API admin page) would offer the option to choose/switch to which version would be used globally per site. Later on, we could have it so modules that work only with specific versions of a library override this global site setting in their settings page.")

For the 3.x branch we are moving to an object-oriented approach that will allow us to override the default loading behavior (which is to bail out, if any version is already loaded) for jQuery in a sub-class, and in that way allow to load more than one version simultaneously. That will probably happen in the jQuery module, though. Also, just as a disclaimer, it is also quite a ways off, for now.

For now I have only ever heard this feature request when speaking about jQuery, so adjusting the title accordingly. In general, or as a default, I still think we need to enforce that only one version of a library exists at any time.

I am still leaving this as a feature request, as we should make sure that we allow jquery.module to implement this behavior in a sane way. I might mark it "normal" rather than "major" but can't decide on that right now, so leaving for now. :-)

Righto. "Multiple versions in parallel" is definitely limited to front-end libraries, and out of those, only a handful support that concept in the first place.

I'm not exactly sure to which extent we can support this directly in Libraries API, since the entire idea is sorta detrimental to Libraries API (as well as Composer) in the first place -- the goal is to rely on a single library instead of multiple versions instead. I'm pretty sure that Composer doesn't support that concept at all and bails out with an error message along the lines of that conflicting dependency versions have been specified, so dependencies are not resolvable.