| Gábor Hojtsy (he/him) |
Last meeting we discussed[#3473440], all but one of those got committed and released in Drupal 11. |
| Gábor Hojtsy (he/him) |
https://www.drupal.org/project/drupal/issues/3477375 is outstanding still |
| Gábor Hojtsy (he/him) |
We added a rule to Upgrade Status to categorize these issues as "ignore", which should help with running on older versions of Drupal 11. |
| Gábor Hojtsy (he/him) |
Despite the spaceless issue not committed to core yet, Upgrade Status' test suite is not producing it anymore, so I think project update bot can (or already did?) continue operation. cc @bbrala who would know more. |
| bbrala |
I will get to projectbot again soon. |
| bbrala |
I saw your commits, so that triggered me. 🙂 |
| Gábor Hojtsy (he/him) |
Thanks @bbrala for the attempts at fixing tests, even though thankfully core fixed earlier than us powering through those :see_no_evil: |
| bbrala |
haha, yeah, i kinda gave up on those and started helping on the core side back then.Spaceless seems close also. @nod_ was quite helpfull there, hopefully he can come back and verify the progress by the other contributors. |
| finnsky |
For spaceless i’ve fixed visual regressions. And also added suggestion to port that drupal_spaceless to contributed module[#3477375]#comment-15805368 |
| bbrala |
Seems someone even got the option to fix it on core working. Which confuses me a lot :sweat_smile: |
| finnsky |
not sure exactly how it should happens in deprecation style. but core not need that new filter globally. |
| Gábor Hojtsy (he/him) |
Suggested by @berdir 🙂 |
| Gábor Hojtsy (he/him) |
Any docs we should link? 🙂 |
| berdir |
https://www.drupal.org/drupalorg/blog/gitlab-ci-templates-will-make-drup... I guess |
| berdir |
result is that you might see tests fail on merge requests you create/updated in projects that aren't compatible yet. Or, if projects needed workarounds to get D11 tests to run like using lenient/patches for dev dependencies, that needs to be updated and applied to the default composer version now |
| lleber |
What's the next major run on now? |
| berdir |
nothing |
| berdir |
automatically skipped until 12.x branch is created |
| berdir |
previous minor is also skipped at the moment, will run again as soon as 11.1.0 is out, so you can keep that enabled and it won't break |
| berdir |
and current is now actually 11.0.latest, not 11.x (11.1) development branch, so more stable than next major was before |
| lleber |
Ah nice...so running tests on previous and next will have the versions automagically managed by the DA moving forward? |
| berdir |
yes. it was always automatically managed, but now they're also automatically disabled if there's no matching branch for a certain next/previous setting |
| James Shields |
I've verified that next major and previous minor are being skipped. |
| James Shields |
I feel that since 10.2 and 10.3 are both supported at present, it would be nice to have an easy way to run tests against both. At present, previous minor tests on 10.3, but I think unless you set up an explicit test for 10.2, it's left out in the cold. |
| lleber |
I kinda agree there. Having spent the time customizing all but 3 of my contrib modules' .gitlab-ci.yml files to test on current + next, it seems to have been just in time to have to refactor them again to run against "all currently supported core versions" :confused: |
| James Shields |
Actually a single OPT_IN_TEST_ALL_SUPPORTED flag that ran against all the current supported versions might be a neat way to do it. |
|
Obviously we're not counting 7.x as a supported version for this! |
| fjgarlin |
Creating variants is very easy https://project.pages.drupalcode.org/gitlab_templates/info/variants/#cre... |
| lleber |
Individually, sure, but the time suck really adds up if you have to configure dozens of projects + cut releases :confused: |
| fjgarlin |
“Testing all” could be a big costly pipeline that we might not want to encourage or allow easily. Tho remember that each maintainer can fully customize the gitlab ci file to the project needs |
| lleber |
Not sure if there's an equivalent, but this is what we do with our github hosted modules: https://github.com/PSU-OOE/drupal-module-qa-action/blob/main/action.yml |
| fjgarlin |
You can have a centralized file and then reference that file from those dozens of projects too 🙂 |
| lleber |
It's an interesting note that the cost to test a contrib module against all supported core versions can be a factor. Suppose it's always a balance between stability, cost, and actual support ranges.I'm of the mind that if tests aren't running against a particular version, it's worse than unsupported, because it's advertised to work, but nothing is checking to make sure it actually does. |
| fjgarlin |
We have up to 5 variants (not all run by default but all of them are easy to customize) that help cover a good deal of versions out of the box |
| lleber |
Presently, 10.2, 10.3, and 11.0 are the only supported core versions, right? |
| lleber |
Given Drupal's support model, it's usually a max of 3 supported minors at any given point in time..? |
| lleber |
Ah, nevermind -- seems like it'd be up to 6.10.x-security, 10.x-active, 10.x-dev, 11.x-security, 11.x-active, and 11.x-dev |
| James Shields |
“Testing all” could be a big costly pipeline that we might not want to encourage or allow easily.I think it's potentially one more than enabling all the current opt-in variable.We've gone from enabling everything testing against 5 versions, to 3 versions, so if there's a time to implement with minimum impact, this would seem to be it.But if you think that's making things too easy to use a lot of resources, I still think defining a variable called something like "OPT_IN_TEST_PREVIOUS_SECURITY" or something like that to pick up the security release of the previous major version. |
| lleber |
I think another* stance here is that a more opinionated direction for contrib could be really beneficial to the cause. Instead of every contrib maintainer individually "figuring it out" for their projects, is there an option to just give the reigns to the DA and never have to worry about it again? (edited) |
| lleber |
Presently, contrib has to commit a file manually to enroll into testing, even if it's the default template (at the exact time they commit it). |
| James Shields |
I do think tests need to be "opt in". For one thing there are a lot of abandoned or unmaintained modules that would suddenly opt in - though I guess they wouldn't be tested unless people were opening merge requests. |
| James Shields |
But I think an easier way to opt in to "best practice" tests would be beneficial. |
| lleber |
Automatically marking unsupported if tests haven't been passing in N majors seems a more honest approach. |
| Gábor Hojtsy (he/him) |
See https://drupal.community/@dropismoving/113329878372126989 🙂 |
| Gábor Hojtsy (he/him) |
There is guidance to implement new OOP hooks in a way that is backward compatible with Drupal 10 too there. |
| Gábor Hojtsy (he/him) |
(Not as nifty to screenshot though :D) |
| bbrala |
Was happy to see DeprecateionHelper in the CR here. |
| bbrala |
And EXTREMELY happy we can stop with magic functions :stuck_out_tongue: (edited) |
| lleber |
What exactly does the long-term future for hooks look like? Can we expect Drupal majors to start dropping support for procedural hooks, or will both remain in tandem for the foreseeable future? |
| lleber |
In other words, what B/C ROI can be expected? Why should clients pay to have hooks OOP'd? (edited) |
| moshe |
The CR states that hooks are being deprecated and will be removed eventually |
| moshe |
There is a rector that will OOP existing implementations. Its a small level of effort, even on a big site. |
| lleber |
I see now. Missed that.In a later Drupal version (Drupal 12 at the earliest), we expect that support for procedural hooks will be removed, at which time these services and the LegacyHook shims will need to be removed as well.So 2026 is the rough earliest possible end of procedural hooks. |
| Gábor Hojtsy (he/him) |
Yeah minor releases can't remove hooks or support for them. |
| pingwin4eg |
Hello. @fabianx raised a good question regarding arbitrary namespace for a service class with hook attributes in[#3442009]#comment-15568818.I wanted to ask if there is a follow-up issue yet. Or can we discuss it here? |
Eric (sikofitt), Berdir, finnsky, James Shields, Gábor Hojtsy, Nick Dickinson-Wilde, bbrala, Luke.Leber, , fjgarlin, moshe, pingwin4eg
Comments
Comment #2
gábor hojtsyComment #3
smustgrave commentedMissing a few threads.
Comment #14
smustgrave commentedComment #15
smustgrave commented