Deprecate HAL module

- Added draft CR
- Added lifecycle_link entry linking to above CR

Note: The link to the contributed HAL module (https://www.drupal.org/project/hal) currently returns a 403.
Also unsure if it's supposed to link to a CR, I see that the Tracker module opted for a link to https://www.drupal.org/about/core/policies/core-change-policies/deprecated-and-obsolete-modules-and-themes

I was of the impression that the lifecycle links where to go to handbook pages, not CRs

Check the forum and tracker deprecation issues to see the handbook page they're using in the lifecycle link

I was of the impression that the lifecycle links where to go to handbook pages, not CRs

If that is indeed the official policy, I'll happily comply.
And in the process, that would answer #3261679-7: Deprecate tracker module in Drupal 10.1.x and #3261452-14: [11.x] Remove tracker module from core.

So if Somebody With The Power could confirm, that would be a lot of birds with a pebble kinda thing.

Yeah let's use https://www.drupal.org/about/core/policies/core-change-policies/deprecat...

I'll fix up the forum one - I added a new one because I couldn't find an existing one

And yeh, I think we should link to the node/{nid} instead of the path alias just to be safe

Postponing on #3263654: Move all HAL tests to the module in preparation of removal in D10

Blocker #3263654: Move all HAL tests to the module in preparation of removal in D10 is in, un-postponing.

@bbrala, @larowlan: This would be an excellent time to get https://www.drupal.org/project/hal filled with the current core hal module.

This going to get in against 10.0.x-dev first, and insta-backported to 9.4.x-dev like any other issue in the current queue.

This is going to get in against 10.0.x-dev first, and insta-backported to 9.4.x-dev like any other issue in the current queue.

As can be seen in https://www.drupal.org/pift-ci-job/2323653 the tests in core/tests/Drupal/KernelTests/Config/DefaultConfigTest.php trigger a deprecation notice whenever a Core module with config is deprecated.

Postponing on the newly created #3265546: Drupal\KernelTests\Config\DefaultConfigTest throws deprecation notice for deprecated Core modules/themes which have config where we're going to solve this.

Added you to the contrib project @Spokje so we're not a blocker

If you beat us to it, please use a subtree split so we keep the history

Added you to the contrib project @Spokje so we're not a blocker

@larowlan Erm....thanks? As I've proven many times before (especially on these deprecate/remove Core module issues) I'm quite capable of creating my own blockers ;)

If either you or @bbrala can do this, that would be great. I'll see what I can do/understand of all this git-wizardy and contrib module creation shizzle if this becomes the only blocker (which would be around 63.0.x-dev by the looks of it...)

Thanks @bbrala.

The failure is fully outside hal (and about deprecation, which isn't happening in the Contrib hal module).

So: Split the subtree, you can!

@bbrala and @larowlan Just discovered #3264633-18: Remove \Drupal\layout_builder\QuickEditIntegration and refactor it so that quickedit contrib provides the integration with layout builder which means it seems smarter to wait for that issue to land before contribifying to prevent double work (and Yet Even More Admin with double issues in Core and Contrib).

No longer postponed, #3263654: Move all HAL tests to the module in preparation of removal in D10 has been committed.

Setting to NW because of a failing test. I notice the lifecycle_link is https://www.drupal.org/node/3223395#s-hal should it not be the CR for this issue?

I'm adding to the remaining tasks with some of what is under discussion in #3266219: [policy, no patch] Document the approach and issue scope for removing modules from core just to give them a test and see how it goes.

Forgot to change the title.

Thanks @quietone.

Sadly putting back to postponed on #3265546: Drupal\KernelTests\Config\DefaultConfigTest throws deprecation notice for deprecated Core modules/themes which have config.4

I notice the lifecycle_link is https://www.drupal.org/node/3223395#s-hal should it not be the CR for this issue?

We decided to go to the d.o. page here: #3263618-10: Deprecate HAL module

Went through the remaining tasks (thanks @quietone) and updated them

Sorry for the noise, updated the IS again and updated the Currently postponed on: section.

Let's see.

TestBot green.

Tagging with 9.4.0 release notes (just because I'm an optimist).

This looks like (well...actually is) a _huge_ MR, but it all boils down to:

• Adding a lifecycle: deprecated and accompanying lifecycle_link to core/modules/hal/hal.info.yml.
• Tagging all tests in the hal module with @group legacy to make PHPStan happy.

Both Mr's look good. Just a single question.

Should this not be: lifecycle: obsolete?

Obsolete is only for when a module is gutted and needs to stay in core so it can be uninstalled. Examples would be entity reference. A non-standard example is simpletest where we provided a contrib version but also added an update to uninstall it in core (since it's a dev dependency and should never have been installed on anyone's live site anyway). So it exists purely because you can't uninstall and remove a module in a single release, you have to remove the .info.yml only once you know that the uninstall has run on every possible site.

For modules we're moving to contrib, we can't/won't uninstall the module for people automatically. They either need to uninstall it themselves before updating to 10.0.x, or install the contrib module, so 'deprecated' is correct, even right up until removal. If someone updates without taking any action, they'll get a big error message, but that error message is what we need for that case.

@catch Thank you for the explanation.

All code changes on both MR's look good to me.
For me it is RTBC.

Bye bye HAL module.

Thanks @daffie for the review and @catch for the reply. Resolved thread.

BTW: MR!1799 against 9.4.x is outdated, or at least not correct IMHO.

Although technically that branch wouldn't need to tag all the tests in the hal module with @group legacy (since no PHPStan there), I think they still should be marked as such.

A straight backport of MR!1853 would apply and do the above.

Unwanted (Dear Lord, _VERY_ unwanted) Status change, back to RTBC

This looks great. I'm planning to commit it as soon as there's a stable release on https://www.drupal.org/project/hal

Committed f26bc10 and pushed to 9.4.x. Thanks!

Published changed record