Closed (fixed)
Project:
Sessionless BigPipe
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
7 Apr 2019 at 11:12 UTC
Updated:
23 Jun 2020 at 08:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
wim leersComment #4
wim leersJust one deprecation notice:
Will fix.
Comment #5
wim leershttp://hojtsy.hu/blog/2019-oct-16/join-imadedrupal9-drupalcon-amsterdam-...
Comment #6
dmytro-aragornGoing to work on this issue during DrupalCon Amsterdam Contribution day.
Comment #7
dmytro-aragornAdding a patch.
No deprecated issues found.
Comment #8
gaëlgThis patch applies on latest dev, the changes seem reasonable, automated tests passed and Upgrade status module found no problem.
Comment #9
chegor commented+1 for RTBC
Comment #10
wim leersThis must be at least
8.7.7. That also means we can drop thecore: 8.xline. And it means we can simplify our dependencies.Everything else looks great, thanks! 👍
Comment #11
wim leersComment #12
wim leersForgot the
big_pipe_sessionless_test.info.ymlfile 😬Comment #14
wim leersWithout 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.
Comment #15
wim leersAnd now for part 2.
Comment #17
wim leersBecause core BigPipe tests use the
classy, we must too.Comment #18
wim leersComment #19
wim leersSo 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.
Comment #21
wim leersThanks @alexpott for the rubberducking/thinking to figure out the puzzling behavior in #18 🙃
Comment #22
wim leersComment #24
dom. commentedWim 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:
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
Comment #25
wim leers@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.
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.xbranch and the2.xbranch shortly; I'll set this issue to at that time.Comment #26
wim leersI will unpublish the
8.x-1.3release and instead release a2.0version that is compatible with Drupal 9. I will revert both commits to the8.x-1.xbranch that this issue made.Comment #27
wim leersUGH I picked the wrong patch for the
2.xbranch 😬Comment #28
wim leersComment #30
wim leers#28 shows that the approach proposed in #25 + #26 works:
8.x-1.xis D8-only and does not bump the PHP version requirement2.xis D9-only and also works on PHP 7.3, unlike the8.x-1.3release I made last weekAFAICT this addresses all of @Dom.' s concerns. Please confirm! 🙏
Comment #31
dom. commentedHaving 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 !
Comment #34
wim leersExcellent, thanks!
The one thing I disagree with is to tag a
8.x-1.4release. Like I wrote in #26: I will unpublish the8.x-1.3release, so that8.x-1.2is again the latest. Because literally nothing changed since8.x-1.2: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