Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

Status: Active » Needs review
StatusFileSize
new737 bytes

Status: Needs review » Needs work

The last submitted patch, 2: 3046409-2.patch, failed testing. View results

wim leers’s picture

Just one deprecation notice:

Remaining deprecation notices (2)

  2x: assertNoCacheTag() is deprecated and scheduled for removal in Drupal 9.0.0. Use $this->assertSession()->responseHeaderNotContains() instead. See https://www.drupal.org/node/2864029.
    2x in BigPipeSessionlessTest::testBigPipeNoSession from Drupal\Tests\big_pipe_sessionless\Functional

Will fix.

wim leers’s picture

Title: Ensure the Sessionless BigPipe module is compatible with Drupal 9 the day it is released » Drupal 9 plan
Issue tags: +Amsterdam2019
dmytro-aragorn’s picture

Going to work on this issue during DrupalCon Amsterdam Contribution day.

dmytro-aragorn’s picture

Status: Needs work » Needs review
StatusFileSize
new4.66 KB

Adding a patch.
No deprecated issues found.

drupal-check -d big_pipe_sessionless/
 10/10 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%


 [OK] No errors
gaëlg’s picture

Status: Needs review » Reviewed & tested by the community

This patch applies on latest dev, the changes seem reasonable, automated tests passed and Upgrade status module found no problem.

chegor’s picture

+1 for RTBC

wim leers’s picture

StatusFileSize
new680 bytes
new4.97 KB
+++ b/big_pipe_sessionless.info.yml
@@ -3,6 +3,7 @@ type: module
+core_version_requirement: ^8 || ^9

This must be at least 8.7.7. That also means we can drop the core: 8.x line. And it means we can simplify our dependencies.

Everything else looks great, thanks! 👍

wim leers’s picture

Title: Drupal 9 plan » Drupal 9 compatibility
wim leers’s picture

StatusFileSize
new625 bytes
new5.53 KB

Forgot the big_pipe_sessionless_test.info.yml file 😬

  • Wim Leers committed c2b79e6 on 8.x-1.x
    Issue #3046409 by Wim Leers, dmytro-aragorn, GaëlG, chegor: Drupal 9...
wim leers’s picture

Title: Drupal 9 compatibility » Drupal 9: installable

Without this patch getting committed, DrupalCI won't be able to install this on D9. I know for a fact that we'll need more changes, for example https://www.drupal.org/node/3083055, but that's impossible to see now. So let's commit #12 and then continue from there in this same issue.

wim leers’s picture

Title: Drupal 9: installable » Drupal 9 compatibility
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new1.13 KB
new1.13 KB

And now for part 2.

Status: Needs review » Needs work

The last submitted patch, 15: 3046409-15.patch, failed testing. View results

wim leers’s picture

Status: Needs work » Needs review
StatusFileSize
new1.13 KB
new1.13 KB

Because core BigPipe tests use the classy, we must too.

wim leers’s picture

StatusFileSize
new2.25 KB
new3.05 KB
wim leers’s picture

StatusFileSize
new504 bytes
new3.54 KB

So as per #18

PHP 7.3 & 7.4 behave differently:

So, we can have either D9 + PHP 7.4 or D 8.x + PHP 7.3, but we can't have D9 + PHP 7.3 in the same branch. I don't want to create a new branch just for this, so I'm gonna bump the PHP required version to PHP 7.4. Per https://www.php.net/supported-versions.php, PHP 7.3 support ends in 6 months anyway. If you're moving to D9, you are probably moving on to PHP 7.4 anyway.

wim leers’s picture

Status: Needs review » Reviewed & tested by the community

Thanks @alexpott for the rubberducking/thinking to figure out the puzzling behavior in #18 🙃

wim leers’s picture

Status: Reviewed & tested by the community » Fixed

  • Wim Leers committed 80e8c66 on 8.x-1.x
    Issue #3046409 by Wim Leers, alexpott: Drupal 9 compatibility
    
dom.’s picture

Wim Leers: I just see a new module version (8.x-1.3) which is only compatible with 7.4 while D8.9 is compatible with every PHP7 versions (but garanteed 7.3 and 7.4 as explained in its release note).

That means, I can update everything on my client site to latest using `composer update --with-dependencies` but this module make it fails:

INCOMPATIBLE MODULE
The following module is installed, but it is incompatible with PHP 7.3.15:
Sessionless BigPipe

My question: would it be better to release this module under a new major version number 8.x-2.0 for instance (or 2.0.0 to move to semantic versionning) so that you don't have to commit another composer.json to fix the version number of this module to 8.x-1.2 (thus always having it pop as updatable in drupal UI, which the client dislikes !).
It does not feel like compatible with D8.7.7 as it stands in the core_requirements that way.

Could you advice on this ?
Thanks

wim leers’s picture

Status: Fixed » Active

@Dom.: 👋🏻 Long time no see!

See #19 for my reasoning. Symfony forced the signature change. I had to choose between multiple branches or bumping the required PHP version. I chose to bump the required PHP version since PHP 7.3 will be EOL in 6 months anyway.

It does not feel like compatible with D8.7.7 as it stands in the core_requirements that way.

This is true; I should've updated that in #19 too 😬

My choice was rooted in pragmatism, but obviously it's causing disruption for you. And truth be told, a PHP version requirement bump is a trigger for a new major version per semver.

So … I'm going to do exactly what you suggested. I'll ask you to verify what's in both the 8.x-1.x branch and the 2.x branch shortly; I'll set this issue to Needs review at that time.

wim leers’s picture

Status: Active » Needs review
StatusFileSize
new2.26 KB
new7.2 KB

I will unpublish the 8.x-1.3 release and instead release a 2.0 version that is compatible with Drupal 9. I will revert both commits to the 8.x-1.x branch that this issue made.

wim leers’s picture

StatusFileSize
new1.83 KB

UGH I picked the wrong patch for the 2.x branch 😬

wim leers’s picture

StatusFileSize
new7.2 KB
new1.83 KB

The last submitted patch, 28: 3046409-28-8.x-1.x.patch, failed testing. View results

wim leers’s picture

#28 shows that the approach proposed in #25 + #26 works:

  1. 8.x-1.x is D8-only and does not bump the PHP version requirement
  2. 2.x is D9-only and also works on PHP 7.3, unlike the 8.x-1.3 release I made last week

AFAICT this addresses all of @Dom.' s concerns. Please confirm! 🙏

dom.’s picture

Status: Needs review » Reviewed & tested by the community

Having 2 separate branches is currently the best approach I guess. That is what I do with my modules currently (Search Autocomplete lately for instance).
The whole thing to not have a new 9.x branch with separate modules for D8 and D9 makes is weird compared to what we have been used to for the last decade, but that is another story... My decision is to let an active yet "un-recommanded" branch for all-version D8 users and move on D8.8/9 in the recommanded branch.

Regarding the need to not enforce the PHP7.4 dependencie I have another 2 cents about it :
when you dev on windows, you are likely to use "Acquia Dev Desktop" to serve your site. The last version at the time of today does not embed PHP7.4 so that means even on local environment one would not be able to use the last current release of this module.

As far as #28, here is what I tested :

For D8:
- Using Composer to get the last version : 8.x-1.3 it is indeed restricted to PHP7.4 as stated previously, so I could not enable it.
- Using cweagans/composer-patchesto composer patch the module using patch #28 did not work since the patch does not apply in that situation. That enphasis the necessity release a new 1.4 when patch is validated since even with #28 around, you cannot patch/deploy.
- Using git, the patch applies properly to 8.x-1.x branch (dev) and the module is activable without apparent complication.

For D9:
Following the same test procedure, composer could actually patch the module install so that was not an issue on D9.

Both testing are made with a fresh D8 and D9 install on the Umami profile.

For the above reasons, I move the issue to RTBC and looking forward to the new releases. Thanks a lot for help, and my client will also be happy to see his updatable module list to green !

  • Wim Leers committed 387f6df on 8.x-1.x
    Issue #3046409 by Wim Leers, Dom.: The 8.x-1.x branch can not be...

  • Wim Leers committed a38c422 on 2.x
    Issue #3046409 by Wim Leers, Dom.: The 2.x branch supports only Drupal 9...
wim leers’s picture

Status: Reviewed & tested by the community » Fixed

Excellent, thanks!

The one thing I disagree with is to tag a 8.x-1.4 release. Like I wrote in #26: I will unpublish the 8.x-1.3 release, so that 8.x-1.2 is again the latest. Because literally nothing changed since 8.x-1.2:

$ git log --oneline -n 5 8.x-1.x
387f6df (origin/8.x-1.x, 8.x-1.x) Issue #3046409 by Wim Leers, Dom.: The 8.x-1.x branch can not be compatible with Drupal 9 if it must also continue to support PHP 7.3 due to a Symfony-forced function signature change
80e8c66 (tag: 8.x-1.3) Issue #3046409 by Wim Leers, alexpott: Drupal 9 compatibility
c2b79e6 Issue #3046409 by Wim Leers, dmytro-aragorn, GaëlG, chegor: Drupal 9 installability
7031e80 (tag: 8.x-1.2) Issue #2962008 by Wim Leers: Coding standards: comply with as much of the 'Drupal' coding standard as possible, add phpcs.xml to opt out of a few rules
5125289 Issue #2942484 by Wim Leers, ABaier, notnotnate, glass.dimly: HEAD requests: "Notice: Undefined offset"
$ git d 8.x-1.2 8.x-1.x

Unpublished https://www.drupal.org/project/big_pipe_sessionless/releases/8.x-1.3. Released https://www.drupal.org/project/big_pipe_sessionless/releases/2.0.0

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.