Problem/Motivation
drupal/core-dev-pinned allows developers to run tests using exactly the same dependencies as a specific version of core. drupal/core-dev is similar but allows newer versions to be installed. In practice there is usually little difference between these.
However, when security updates are released for dev dependencies such as Composer, this means that drupal/core-dev-pinned is stuck on an insecure version until we release a newer version of core itself, while drupal/core-dev can freely upgrade.
At the time of writing drupal/core-dev on Packagist has nearly 20 million installs, while drupal/core-dev-pinned only has 250,000 - or 80 times fewer - so it is clear drupal/core-dev is preferred and we are not really seeing any issues by being more relaxed in the allowed dependencies.
Steps to reproduce
Proposed resolution
Deprecate drupal/core-dev-pinned and recommend that users use drupal/core-dev instead.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3566600
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
longwaveComment #3
longwaveComment #5
longwaveInitial attempt at this, I think we don't need to keep this into Drupal 12 as users can just swap to drupal/core-dev, but we should maintain it for the rest of Drupal 11. Also needs a change record.
Comment #6
quietone commentedAdded a change record and related issue.
Comment #7
quietone commentedComment #8
quietone commentedWhatever style of change is decided on here for description text of the metapackage should be added to the 'how to deprecate' page.
Comment #9
longwaveGood idea - one day we will also want to deprecate drupal/legacy-project.
Comment #11
smustgrave commentedRecommended way to test this?
Comment #12
longwave@smustgrave Not really sure. Once this is committed, the
abandonedline incomposer/Metapackage/PinnedDevDependencies/composer.jsonwill in turn be committed to https://github.com/drupal/core-dev-pinned/blob/main/composer.json - which in turn will mark https://packagist.org/packages/drupal/core-dev-pinned as abandoned, but I don't know of a way of testing that outside of Packagist.The documentation for this feature is at https://getcomposer.org/doc/04-schema.md#abandoned
Comment #14
dcam commentedI rebased the MR because it was 316 behind and I wanted to review it. The test pipeline says I don't have permissions to run the tests, which is something I haven't seen before. Does anyone have an idea of what that's about?
Comment #15
dcam commentedSorry about breaking the MR. I noticed it was targeting the wrong branch. Changing the target was a bad idea. I'll sort it out and make a new MR.
Comment #19
dcam commentedI don't have any additional feedback. I've deprecated a few packages at work and the entries in the composer.json files are good. I checked the composer and core directories to see if there's anything else that should be removed at this time (particularly the metapackage README file), but all mentions of the package and builder are appropriate to stay. They'll be removed from main right away anyway if we try to get this in before D12. This looks good to me. Sorry about the noise from rebasing and then retargeting the original MR.
Comment #21
mstrelan commentedIs it worth adding a
hook_requirementssomewhere in core that checks for this? Or is the existing deprecation loud enough to be noticed. Can use something simple like this:Comment #22
longwaveI don't think it's core's responsibility to do that, the person seeing that requirements message might not be able to do anything about it. The warning should appear when using composer, which is the time you can actually take an action to fix it.
The package also has a relatively low number of installs so I don't think it's worth additional messaging.
https://packagist.org/packages/drupal/core-dev-pinned
vs https://packagist.org/packages/drupal/core-dev
Comment #25
catchYeah I think the composer message should be OK, that's the context where you're also able to fix it.
Committed/pushed to main and 11.x, thanks!
Comment #28
quietone commentedAdd how this was done to a 'composer metapackage' section on How to deprecate