Problem/Motivation
We currently have two separate initiatives underway:
Automatic Updates
🌱
Automatic Updates Initiative overview and roadmap
Active
and
Project Browser →
.
For the former, there's already the
Automatic Updates contrib module →
. The 1.x version of it is only for sites with codebases that are not managed with Composer: in other words, primarily for Drupal 7 sites, and also for some Drupal 8 sites that choose to not use Composer despite that limiting the available contrib modules that can be installed. Work has also begun in the 2.x branch of that module for Composer-managed sites, though this is still early (pre-alpha) code.
When the 2.x branch is sufficiently far enough long, that's what will get proposed for addition into Drupal 10 core.
However, I propose that when the module is proposed for addition to core, it should not be named automatic_updates, for 2 reasons:
- It's not ideal for a core module and a contrib module to have the same name. We've done this before (e.g., with the
jsonapi module), but doing so confuses packages.drupal.org with respect to how to resolve drupal/MODULE_NAME_THAT_EXISTS_IN_BOTH_CORE_AND_CONTRIB.
- I think it's a bad name for the core module, because it will contain more functionality than just providing automatic updates. It will also support manual (click a button) updates. And it will eventually also provide the installation functionality for Project Browser. In other words, it will manage
composer require operations in addition to composer update operations.
Given the above, I think a better name would be package_manager.
However, that would create a dichotomy of terminology between "Package Manager" and "Project Browser". The implication of such a naming is that you browse for projects and then for the projects that you decide you want to use on your site, Package Manager managers the installation and updates of the corresponding packages. Except that in this process, "projects" and "packages" are exactly the same thing. Well almost. Each project is a package. However the package might pull in dependencies, where each dependency is also a package, but may or may not also be a project.
I wonder if we would be better off with naming "Project Browser" something more like "Package Browser" or "Package Manager UI"? I know we have a lot of history on drupal.org behind the word "project", but the rest of the world (Composer, npm, operating systems) have settled on the word "package".
Proposed resolution
- Decide on
package_manager as the module name that will implements automatic updates and other package management functionality in core.
- Decide on a name for the module that will let you visually browse for projects/packages that are on drupal.org that you might want to add to your site. My recommendation is that this name include the word "package" in it rather than "project", for consistency with the "package_manager" module.
- If we do the above, then also figure out where else within Drupal's UI and on drupal.org that we should replace the word "project" with "package".
Remaining tasks
Discuss the above proposal and suggest alternate options.
User interface changes
API changes
Data model changes