[policy, no patch] Mark Package Manager as a beta stability core module

Created on 6 May 2025, 28 days ago

Problem/Motivation

Package Manager has fixed its two outstanding beta blockers as a core module. It was committed with alpha stability a while ago, but has been kept in core's code base as a one-time exception to normal policy because it was necessary in order to test updating core using the Automatic Updates module (which relies on Package Manager).

Although Package Manager has quite a few stable blockers and needs triage, its API can now be considered stable. No changes are needed to the module itself in order to mark it as beta.

Release notes snippet

Package Manager is now a beta module in Drupal core. It doesn't do anything on its own, but provides the foundational APIs used by Project Browser โ†’ and Automatic Updates โ†’ . Those APIs are stable and will be backwards-compatible, so it is now considered safe to rely on this module and build other projects on top of it.

๐Ÿ“Œ Task
Status

Active

Version

11.0 ๐Ÿ”ฅ

Component

package_manager.module

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States phenaproxima Massachusetts

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

Comments & Activities

  • Issue created by @phenaproxima
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom longwave UK

    I think all that needs to happen here is that the RMs have to agree that beta stability requirements have been met, and then we update the documentation to match.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    I assume the answer is no, but wanted to ask: I assume the rebranding of auto updates to โ€œUpdate Managerโ€ per ๐Ÿ“Œ [policy] Core module machine name and UI labeling for Automatic Updates Active and others doesnโ€™t impact package_manager at all, right? There are no functions that might need renaming, correct?

    Thanks,
    -Derek

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States phenaproxima Massachusetts

    Correct.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Groovy, thanks.

    Where might one review the list of beta blockers, outstanding stable blockers, etc?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    ๐ŸŒฑ Drupal 10 Core Roadmap for Automatic Updates Active is the main plan issue.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    I'd personally be happier here if the issue summary on ๐ŸŒฑ Drupal 10 Core Roadmap for Automatic Updates Active was a bit clearer. I tried to re-organise it a bit this past week, but it's still hard to see what the stable blocking issues are or aren't, and some issues are open but still in the beta blockers list - I duplicated one to the stable list just now.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Reading https://www.drupal.org/project/drupal/issues/3319030 ๐ŸŒฑ Drupal 10 Core Roadmap for Automatic Updates Active there appear to still be open issues under the beta section (if I'm reading that right) so shouldn't this be postponed on those being completed?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Well this issue includes discussing which of those issues are really beta vs. stable blocking, but yes we should have an accurate issue summary over there. Marking needs work for that I guess.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States phenaproxima Massachusetts

    Updated that issue's summary, moving the TUF stuff to stable blocking.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    So seems all beta blockers for package manager on the roadmap are done, so assuming this is good?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    Sorry about the status wars, @smustgrave, but I think we still need review of the IS updates @catch requested for this to be RTBC.

    I think we would need a lot more clarification/caveats for users about the signing and infra work being deferred to stable-blocking.

    I have concerns with this sentence:

    so it is now considered safe to rely on this module and build other projects on top of it

    The only thing that is safe is the stability of the API. The packages are not actually being signed or validated. This seems misleading in a bad way. :)

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    The other thing is that Package Manager really does not correspond at all to normal expectations of a beta module (which generally means exposed to end users for testing within the application). The module is still marked hidden (and definitely should remain so!!).

    An alternate course of action that I discussed with @phenaproxima in Slack is to avoid the confusing "What is beta really?" question that comes with wildly divergent expectations, and instead have a release note targeting developers something like:

    The hidden, experimental Package Manager module allows Automatic Updates and Project Browser to be tested so that they can eventually be added to future versions of Drupal core. Package Manager is now considered API-stable, and future API changes will be backwards-compatible, so contributed module developers can now rely on its APIs.

    (That with the appropriate things linked as per the 11.1.0 release notes.)

    Or something, please feel free to propose improvements.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    Updating title to include that alternate potential resolution. Are there also places that the decision that the API is stable should be documented in the PM codebase and/or the handbook?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    Updating IS with a revision of #13 incorporating simpler language from the original release note.

Production build 0.71.5 2024