Problem/Motivation

If a library is depending on another library, it might also depend on a specific version of the library. For example, if core updates a library to a new major version, modules and themes depending on that library doesn't get warned about the new major version, even though it might require the module authors attention.

Proposed resolution

Allow specifying library version when depending on a library. Let's discuss if specifying version constrains should be required always when library depends on another library.

Remaining tasks

  • Discuss how to handle conflicts between modules / themes

User interface changes

API changes

Data model changes

Release notes snippet

Comments

lauriii created an issue. See original summary.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Issue summary: View changes
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Assigned: Unassigned » nod_
Category: Bug report » Feature request

The asset library system is completely unaware of versions in dependencies. The version information solely exists as metadata, just like for example the license information.

This would be a significant new feature.

Assigning to @nod_ to get his thoughts.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

nod_’s picture

nod_
Primary language French
Location Lille
commented
Related issues: +#3093175: Document version numbering system for forked jQuery UI components

I'm not too found of adding this type of feature, mainly because I haven't seen much of a problem with it. And I'm not sure what is exactly the goal for this: prevent installing/using something before it breaks on the client side? if yes what kind of thing do we have in mind in order to do that? prevent the module installation altogether?

We also discourage loading different version of the same libraries because it's typically not a good practice to do that : potential conflicts of badly written scripts, and performance issues).

If it is only an "information" issue to force people to pay attention I don't feel it's a good enough reason to do it. In the spirit of being explicit and keeping backward compatibility. If a new version is so different it'll beak things I might naively add a new library with a new name, and update all the dependencies with this new library.

Wouldn't mind some horror stories explaining why and how much this type of feature is needed.

At some point it'll start to look like a package manager, without any of the advantages (everything in manual in the libraries.yml)

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

greg boggs’s picture

greg boggs
he/him
Primary language English
Location Portland Oregon
commented

Here's a use case for us to consider:

https://www.drupal.org/project/views_bootstrap/issues/3300620

Different versions of views bootstrap support different versions of bootstrap. However, since Drupal's dependency system isn't version aware, folks who install their updates get a broken site unless they manually choose the correct versions to match their bootstrap version.

I don't know if the answer is improving this system, or using composer to manage libraries.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.