Add support for Druapl 10.5/11.1

cmlara → changed the visibility of the branch 3528246-add-11.1-10.5 to hidden.

On 11.2:
Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "s3fsfileservice", path: "plugin.manager.archiver -> s3fsfileservice -> s3fs.mime_type.guesser -> drupal.proxy_original_service.s3fs.mime_type.guesser.extension"

On 10.5:
This looks like some change in the test runners is again breaking tests on non-critical deprecation.

🐛 Separate MIME type mapping from ExtensionMimeTypeGuesser Needs work appears to be the cause of the circular reference
https://git.drupalcode.org/project/drupal/-/blob/2d44347bce438454f160096...

We have our own copy of the mimetype guesser because of the file_system service conflict in the past.

Now the guessers require the file_system directly to access FileSystemInterface::basename().

https://www.drupal.org/project/drupal/issues/3526142#comment-16151180 📌 Update PHPStan to 2.1.17 Active is also likely to impact D11.2 tests runs as we are configed

The issues in #4 for 10.5 were likely due to an out of date origin locally (missing the deprecation silence fixes).

📌 Update PHPStan to 2.1.17 Active may add some complications for 11.2 as core is now forcing PHPStan v2 which is causing us to download mismatched dependencies. Once core releases 11.2.1 I expect composer failures to block all testing.

  - Locking drupal/core (11.2.0)
  - Locking drupal/core-composer-scaffold (11.2.0)
  - Locking drupal/core-dev (11.2.0-beta1)

Considering 10.5 was released a few days ago and we would be 'rushing' 11.2 if we forced it out today we might consider separating D10.5 into its own issue and have 11.2 be a followup a (hopefully) a few days later..

Limiting the scope to 10.5 per @cmlara suggestion

As I mentioned I've went ahead and changed scope a bit.

• I've simplified version constraints
• Enabled testing with previous major version (so 10.x is being tested)
• Add support for PHPStan 2.0 (which generates a lot of issues, probably a separate issue needed to resolve or ignore those)
• 11.2 support should can be handled separately, maybe here 📌 Copy core 11.1.x ExtensionMimeTypeGuesser to s3fs Active

PS I would suggest dropping support of D8 and D9 altogether, as well as PHP7 .. it's not being tested anyway, so is it still working ?

Lets keep this one as the common issue/meta, especially since It is already being linked to.

As I mentioned I've went ahead and changed scope a bit.

We should avoid the scope creep, Changing the testing environment (not required to test this, see https://git.drupalcode.org/issue/s3fs-3528246/-/pipelines where manual runs were used to determine the information above)(this was a key feature of how gitlab_templates was designed to replicate older drupal_ci, although I admit many developers have never learned about it) and adding support for PHPStan 2.0 are indeed both likely reserved to their own issues. (I haven't even looked at the 2.x problem yet to see how it impacts our ability to run against ^10 and ^11)

Smaller the changeset the quicker I can approve and release a targeted 10.5 instead of having to review everything related to ^11.2 before push.

I've simplified version constraints

Did have simplifying slated into this issue, although I will note I saw <10.6 and thought "wait 10.6 doesn't exist yet" before noticing the lack of an = sign. Technically its as equivalent to what was initially proposed in the MR to simplify, I'm not sure which does a better job conveying the logic, open to community feedback.

PS I would suggest dropping support of D8 and D9 altogether, as well as PHP7 .

Discussed elsewhere, short version my opinion is that (under semver) these all require a major release. Technically we could get away with it as we are not semver yet however there is no need for us to not treat 8.x-3.x as equivalent to 3.x.0 as much as possible. I absolutely do NOT suggest running it on these old of versions unless you are backporting security critical changes (and I still suggest upgrading). I mentioned elsewhere as it relates do drupal/core we are writing to an API spec (which never really goes EOL) not specific versions of Core (which do go EOL).

It's not being tested anyway, so is it still working ?

While we may not be testing it on the weekly test run (gitlab_templates has been poor on maintaining BC leading to fears of adding it) I do run manual tests back as far as PHP 7.4 Drupal:^9.5 periodically, especially when major code changes take place.

drupal-gitlab-local --variable='_TARGET_CORE=^9.5' --variable='PHP_VERSION=7.4' --variable='PHP_IMAGE_VARIANT=apache' composer phpunit (this should be re-producible on GitLabCi with the same config)

OK (88 tests, 600 assertions)

Generating code coverage report in Cobertura XML format ... done [00:00.771]


Code Coverage Report:        
  2025-06-20 02:57:19        
                             
 Summary:                    
  Classes: 17.95% (7/39)     
  Methods: 37.87% (89/235)   
  Lines:   49.17% (2078/4226)

Eventually I will get back to work on 📌 Convert to Quasar Components Active (last I worked on it I had testing working back as far as ^8.9). Ideally this project would have proper MIN/MAX testing. We have accidentally breached our support as discussed in 📌 PHP7.0 support Active and we are waiting on drupal/coder to allow us to implement 📌 [PP-1] Create Gitlab job to test Minimum PHP Language syntax Postponed so our testing right now is indeed not perfect.

waiting for the update to make the module compatible with drupal 11.2

waiting for the update compatible with drupal 11.2

📌 Allow PHPStan ^2 Active is the current blocker, as the tests runs in this issue indicated it now identifies numerous errors (most legitimate however had previously been baseline ignored, and at least one bug in phpstan-drupal). It is only after working through a significant portion of the reported errors that it became apparent that some will not be 'dual fixable' and the discussions around that have been started.

There is talk that core may roll back its demand for ^2 however that, has of yet, not occurred. End of the day we want/need to know we can expect to have clean testing runs before we formally release support for ^11.2.

I can suggest if site owners want to help avoid this in the future a few items they can consider:
Encourage Core to make only bugfix changes after Beta 1.
Encourage Core to ensure major changes are committed to the repo earlier in the development cycle.
Encourage Core to extend the Beta/RC window lengths to allow contirb more time to update before the production release is made available.
Encourage Core to withhold releases when there is any doubt expressed about the suitability of the release (the PHPStan issues were identified in Slack with a Release Manager however the 11.2.0 release was pushed ahead as it was a week behind schedule).
Encourage Core to make more of its API covered by BC Policy (the primary reason we list 'by minor' rather than 'by major')

With the above said, we are currently only 7 days into the lifecycle of a release that has 1 year until its EOL and have ~6 months until 11.1 goes EOL. Would I prefer this was released the same day (or sooner) than Core, yes, however if core makes last minute major decisiosn that impact contrib there is little to nothing we can do except work through it.

The irony of this issue I actually looked into adding add PHPStan ^2 support in November however Drupal Core's requirements prevented it at the time and it appeared we would be good until ^12 based on discussions with other core devs.

cmlara → closed merge request !81