Contrib.social

Tag 8.x-2.7, and move development to new 3.x branch to focus on Core inclusion

Open on Drupal.org →
Created on 10 February 2023, over 1 year ago
Updated 15 February 2023, over 1 year ago

Problem/Motivation

There is a fair amount of work before get ready for Drupal core
including
📌 Rename Stage to StageBase to clarify its relationship to its subclasses, and add "Stage" suffix to the Updater classes Fixed
📌 Stage no longer needs the config factory Closed: duplicate
📌 Adopt PHP 8.1-only capabilities such as constructor property promotion + drop BC layers Fixed

We also have 2 current issues that would need more BC layers we would just have to remove if we did them in 8.x-2.x
📌 Add new InstalledPackagesList which does not rely on Composer API to get package info Fixed
📌 Refactor exception architecture Fixed

#3334994 also changes the way we determine what package are installed. While this is critical for drupal core because we need it for 📌 Remove our runtime dependency on composer/composer: remove ComposerUtility Fixed , it is probably not important for any of the sites that are using the 2.x version because nobody has complained about the composer/composer dependency and we have not had any problem with the current method not finding the correctly installed packages.

Furthermore #3334994 is not without risks it replaces Composer PHP API calls with the executing the process Composer . The current method of using Composer PHP API has been tested in at least the 130 sites that are using the current module and new method will only have been tested in tests and the limited manual testing we might be able to do. Running process is probably more error prone than calling a PHP API.

While this is risk is needed to get into core and it is not needed for the current 2.x sites. We also have time to test the risk of the new method throughout 3.x development and all core experimental release before stable.

I don't want to overstate the risk though. The new method in #3334994 will probably work fine and it could not cause a failure in applying the update to the site to leave the site in broken state.

Proposed resolution

  1. decide if we to tag 8.x-2.x for 8.x-2.7 or tag an older commit if we think any recent commit would be better to only go into 3.x
  2. Update the project page to document that 2.x is bug/security fixes only
  3. We will need to explicitly state that 3.x is for core inclusion and it is better not to code against this branch. We will break BC and when we get into core at the very least the namespaces will change but also other changes will probably be necessary as merge into core and as we get feedback from core committers and others
  4. Open 3.x
  5. Do not make any releases on 3.x unless we have to and then hopefully Alpha releases where we don't have to put in new BC layers.

The only project that may want to code against our 3.x branch is Project Browser if they were also working to prepare for core inclusion. Of course they would have to keep in mind that BC could break and they may just want to wait until package_manager was in core.

🌱 Plan
Status

Fixed

Version

3.0

Component

Code

Created by

🇺🇸United States tedbow Ithaca, NY, USA

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

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024