Decide on consistent naming for future core modules that implement Automatic Updates and Project Browser functionality

Created on 17 August 2021, almost 4 years ago
Updated 28 May 2025, 9 days ago

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:

  1. 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.
  2. 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

  1. Decide on package_manager as the module name that will implements automatic updates and other package management functionality in core.
  2. 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.
  3. 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

πŸ“Œ Task
Status

Needs review

Version

11.0 πŸ”₯

Component

other

Created by

πŸ‡ΊπŸ‡ΈUnited States effulgentsia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Production build 0.71.5 2024