Contrib.social

Proposal: As pathway to Drupal core use new 2.x.x branch for Composer Based Updates

Open on Drupal.org →
Created on 22 June 2021, about 3 years ago
Updated 8 December 2023, 7 months ago

Problem/Motivation

The Automatic Updates Initiative has been focused on working on core inclusion. While it has taken architecture direction from the 8.x-1.x branch of this module the core progress so far resulted in pretty different code because it will support Composer based installs only and it will be split between Drupal core and other libraries in the PHP-TUF github org.

Because of multiple reasons stated below we are now thinking it might be a better idea to do the first pass at the Composer based approach outside of core first. An obvious place to do this work in this module is in a 2.x.x branch. I am creating this issue to make sure other maintainers of this module are ok with that plan.

The reasons to create a first pass of the Composer Based outside of core(here or elsewhere) are:

  1. A criteria for the beta version of core Auto Updates would be to include package verification via The Update Framework implementation found in the PHP-TUF library and the TUF Composer integration library. For this to actually work we would need the Drupal.org TUF server-side implementation to be done. We could have an Alpha version of Core Auto Update without TUF but Alpha experimental modules are not included in releases so this would be harder for users to test.
  2. It is very unlikely that the Drupal.org TUF implementation and the core integration would be done by 9.3.0, the next core release. Therefore we couldn't get a release for people to test before 9.4.0, the last Drupal 9 minor. If we missed 9.4 this would not be available for Drupal 9
  3. TUF Composer integration will likely have a requirement on Composer 2.1.0. This may stop it from ever being included in Core for 9.x
  4. @todo Drupal product and release managers I think after other reasons(sorry not remembering them now)

The drawbacks for using this module would be:

  1. To create a module that would need as little rewrite as possible when it is eventually moved to core, the 2.x branch would not support tarball installs. Current users of module would have to understand that they could not use the 2.x branch unless they convert their site from a tarball based site to Composer based site. The site conversion would not be in the scope of the 2.x version with a plan for core inclusion
  2. Using a 2.x branch of this module for a Composer based version would mean there could not be major version rewrite for the tarball based version of the module. This may not be a problem since Composer has been the recommended way to use Drupal for quite a while
  3. The alpha without TUF integration would be insecure and therefore expose site owners to risks when testing the module.

I think the benefits of using this module out weight the drawbacks

Proposed resolution

  1. Use a new 2.x.x sematic versioning branch of this module to create a Composer based version of Auto Updates
  2. This version would likely be a complete rewrite based on the current core patches and architectural planning that has already happened for Core. The core work does have a lot of work from this module included though. For instance #3162655: Create Automatic Updates Readiness Checks in new experimental module → started with classes from this module and then has been rewritten somewhat from reviews of @dww, @phenaproxima, @voleger, @heddn and others. It has also gotten multiple reviews by the Drupal UX team
  3. The heavy lifting for Composer would be done by the Composer Stager library being developed for core.
  4. We would try to get as much review as possible from core committers, product and framework managers as we go so they would be familiar as possible with it
  5. An Alpha version of this module could be released without the PHP-TUF integration.

Remaining tasks

We need buy-in from the core committers team, the Automatic Update Initiative team and maintainers of this module.

🌱 Plan
Status

Fixed

Version

2.0

Component

Code

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs release manager review

    It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

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.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024