Automated Drupal 10 compatibility fixes

Drupal 10 is out and Drupal 9 close to EOL. Updating priority accordingly. Hopefully our team will have time to review this soon.
Any active maintainer?

core_version_requirement: ^8 || ...
should be
core_version_requirement: ^8.9 || ...
or at least
core_version_requirement: ^8.8 || ...

What about reflecting the changes in 2.x @Ambient.Impact? 🌱 PWA module 3.x roadmap Active

@Anybody What do you mean? According to https://www.drupal.org/node/3070687 → we need to update core_version_requirement to be D10 compatible. Were you able to enable the module without it?

@czigor #8 tells Drupal the module is Drupal 10 compatible, but code isn't. Code changes are needed as #4 shows.
Apart from that, #12 has to be incorporated.

Is there a reason, that a 2.x release does not exist for this module?

I don't think we should make an old branch Drupal 10 compatible, maybe one of the maintainers can change the MR target to 2.x and generally create a 2.x release?

Ok, I see 2.x is just an old forgotten branch. I'll reroll everything again.

Ok I reverted the rebase on 2.x using reflog and rebased the reverted branch with 8.x-1.x. On to checking for any missing deprecation problems.

@Grevil: The D10 compatibility should be against 8.x-1.x first please.

Independently, we may create a separate issue for 2.x, if it's not already D10 compatible. The situation for 2.x is messy, as you can read in my comment: https://www.drupal.org/project/pwa/issues/3165795#comment-14955764 🌱 PWA module 3.x roadmap Active

8.x-1.x is important here. As you already did the work, you may also instead create a separate issue for 8.x-1.x and use this one for 2.x - but 2.x is not important and should be changed with care. I didn't touch it yet and won't touch it in the near future.

@Anybody, the fixes are now catered towards 8.x-1.x, making compatibility issues to 2.x seems pretty unnecessary.

Although, we need to drop the Drupal 8 support, as the "file_url_generator" service doesn't exist for 8.9 yet, as it was introduced in Drupal 9.3, see this change record → .

As the original maintainer rejected @Anybody's request to reset the 2.x branch to the current state of 8.x-1.x, mainly because of "compatibility problems", he should decide whether we should drop the Drupal 8 compatibility. But without dropping the Drupal 8 compatibility, we can NOT make this module Drupal 10 compatible.

FYI, the module is installable and general functionality works fine with the forks changes. All Incompatibilities are fixed.

@Grevil: Drupal 8 support can be removed from 8.x-1.x, I think. Please create a separate issue or at least MR against 8,x-1.x.
@Ambient.Impact should decide then, how to proceed.

Another nice option I think would be to create 3.x to work on from 8.x-1.x, deprecate 8.x-1.x and once 2.x is cleaned up or finished, merge changes into that.

Currently, 8,x-1.x seems more stable then 2.x and has received more bugfixes. This leads to confusion, like here and nobody seems to actively work on 2.x at the moment.

@Anybody this branch IS against 8.x-1.x!

Then it should be set so :)

Ah, sorry, I see....

Nice work @Grevil! Confirming RTBC for MR!27!

Let's wait for @Ambient.Impact's feedback on #25. Otherwise merge it into 8.x-1.x if there's no response.

Wasn't able to push to the issue fork, but added a composer.json at https://github.com/solve-it-once/pwa/commits/3289196-automated-drupal-10 so it works with https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → . You might want to get this into the MR before merging, in the event the D10 compatibility fixes don't get picked up by composer.

@ao5357 it is generally not recommended to manually add a composer.json, since Drupal will auto generate it.

@Grevil While Drupal.org can add it, I've not seen anyone else say it's not recommended. All the projects I maintain have one for various reasons, e.g. dependencies, maintainer credits, etc. and it all just works fine.

@Ambient.Impact that's correct. What I think @Grevil wanted to say is, that it's questionable if it's the same as Drupal.org creates (and updates) automatically. There are pro's and con's. But there are not many reasons to add it in this issue. But let's focus on the issue itself now. You can decide, if you like the composer.json or not. How are you planning to proceed here @Ambient.Impact?

@Ambient.Impact, my apologies, I thought adding a composer.json without the need of any external libraries outside of Drupal (or without the need of any other composer shenanigans) is actually not recommended! Turns out it just isn't required, ass seen in https://www.drupal.org/docs/develop/creating-modules/add-a-composerjson-... → . No mention of whether it's recommended or not.

@Anybody I'm definitely a fan of keeping the scope of issues to just what's relevant so agreed.

@Grevil No worries!

Switching this to 2.x as of https://www.drupal.org/project/pwa/issues/3165795#comment-14974848 🌱 PWA module 3.x roadmap Active

Made it to escape from local rebase hell! Committed to 2.x!

So we can release 2.0.0 now, deprecate 8.x-1.x and create 3.x as new default branch for further development.

@Ambient.Impact could you please check this finally and take these steps? :)

Just to be cautious, let's first release 2.0.0-rc1, use it for a bit, and if it doesn't introduce any new problems over 8.x-1.x, then we can tag a stable 2.0.0 - how's that sound?

@Ambient.Impact perfect! :) Thanks!

Waiting with baited breath for a tagged release w/ Drupal 10 support

@heddn I'll do so ;)

let's first release 2.0.0-rc1, use it for a bit

On it!

@heddn: 2.0.0-rc1 is out! Feedback welcome.

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