Drop Drupal 9 support?

Yes. There is no way IMO to make the module fully compatible with D11 and preserve D9 compatibility without, at a minimum, a lot of conditional code. And since there is no testing against D9 and PHP 7.4, it's likely there are already problems that we don't know about when trying to use Flag in D9 and it's too easy to accidentally add some little thing like a PHP 8 syntax feature that will break a legacy site running PHP 7.4 and Drupal 9.

My suggestion would be to keep the current 8.x-4.x branch for D9 support, if you still want to support D9 (although D9 has be EOL for a year now), but make a new branch for further development. Focus on the future and on making changes/improvements going forward, and you can always backport any bug fixes to the old 8.x-4.x branch if there is time and demand.

I suggest making a new branch for ^10.3 | ^11 and take this opportunity to switch to semantic versioning (5.0.x) because the changes that will be required to use the new APIs in D11 (e.g. PHP Attributes for Hooks and Plugins) and to address the years of unresolved issues will necessarily amount to major changes and require a new major branch.

I think dropping D9 will happen naturally at some point when switching to newer APIs and removing deprecations, not sure if an active push for that is necessary.

I don't know what full compatibility with D11 means, this module is working fine on D11 and all tests are passing. Being deprecation free is a running target, every new minor there are and will be new deprecations, that doesn't mean that the module is not fully compatible.

Strong disagree on new major version to update the core requirement. that can be done in a regular release. new Hooks are fully backward compatible with LegacyHook all the way back, 10.3 buys us nothing for that. What would require 10.2 is adding attribute discovery for our own plugins.

I think dropping D9 will happen naturally at some point when switching to newer APIs and removing deprecations, not sure if an active push for that is necessary.

Active push? It's just removing a few characters from the .info.yml. And since there is no D9 testing to confirm the module is still working on D9, it may already be incompatible in fact. Just one PHP 8 feature added to the codebase and the module will no longer meet core PHP requirements for example. It's about accuracy in the dependencies, so if you're going to lose D9 compatibility IMO it is better to declare it deliberately than to find out sometime in the future that it got broken along the way. And dropping compatibility stealthily as part of some other patch that needs D10 features, rather than in a dedicated issue like this, is not a good practice as far as I'm concerned.

Dropping D9 explicitly right now will reduce the workload, not increase it.

The problem is that there are a lot of things that can be done right now if 10.3 were the minimum, which can't be done if D9 is the minimum. One (unimportant) example is 🐛 Drupal::service('renderer')->renderPlain is deprecated since 10.3.0 Active , but there are many others. You can postpone everything that requires 10.3 or above until at some point in the future when D9 support gets dropped, or you can take the step right now and drop D9 and start to address these things one by one over a period of time. Spreading things out make maintaining the module easier IMO.

I don't know what full compatibility with D11 means, this module is working fine on D11 and all tests are passing. Being deprecation free is a running target, every new minor there are and will be new deprecations, that doesn't mean that the module is not fully compatible.
Yeah, I don't mean deprecation free. And I don't mean it doesn't work in D11. I mean that to take advantage of all the newer APIs, which do bring advantages, means we have to stop supporting the old APIs at some point. The 10.2/10.3 boundary is a natural place, because that's where core has drawn a line in terms of APIs and upgrade functionality. And there are differences in versions of PHPUnit and other test dependencies between D11 and D10 and D9. I mentioned Attributes as examples, and with the new Hook yes we have a LegacyHook system that goes back to 10.1 I think? But not back to 9.1.

Strong disagree on new major version to update the core requirement.
That's not what I said.
I said a new major branch for new major features and new APIs. Core version is not the reason for a new branch. A lot of those changes can't be done unless you raise the minimum supported core version, so some changes to core dependency naturally happen as a side-effect. And a lot of things can't be done unless you have a new major branch, because they constitute major changes.

Are you arguing against dropping D9 support right now? Because that's the question here. The way you go about it is up to you as a maintainer, I'm just offering suggestions of what I have found to work well for managing changes across the core major versions without having to make a continuous effort to keep preventing patches and new features from breaking compatibility with obsolete core versions and without having to put in conditional code that does things differently depending on the core version.

Note the module might become incompatible with Drupal 9 just by implementing D10+ coding standards, for example see the Domain module: 🐛 The website encountered an unexpected error. Please try again later. Active

If you want to explicitly support Drupal 9 (and thus PHP7), better test for it.

I'd argue explicitly supporting the lowest supported Core version according to https://endoflife.date/drupal ends up a much smoother experiences for developers as you don't get incompatible updates through composer.

I totally agree with @TR (sorry @Berdir)

I asked because I want to use JS ES6 instead ES5 and want to use new cool features of PHP 8.1

I'm not against dropping D9, just think it's not really worth it "just because". If there are reasons, sure, I did it most projects already because there were non-trivial deprecations and I didn't want to spend time writing complex BC code. It wasn't necessary in flag so far.

What I am against is starting a new major version before 1.x is stable.

If we increase the version, I'd suggest 10.2, since that is still a supported core release for now or we wait until 10.4 is out and 10.3 is the minimally supported version. 10.3 would allow to switch most plugins to attribute discovery, but not entity types since they aren't supported yet, so we can't do everything yet until we require at least 11.1 anyway (assuming it gets in before that is tagged). 10.2 is enough to do attribute discovery of our own plugin types. The renderPlain() thing is a triviality.

Part of semver/BC is allowing people to prepare for major changes, so we can add attribute discovery and other features in an 8.x-1.x release as long as we include the BC support.

For the record, PHP version and core version are separate things, it would be possible to require a specific PHP version and still support an older core version. Kind of similar for ES6, although we can't specific it the way we could a PHP dependency. In this case, requiring 10.x is easier/easy, but we could for example require 8.3 in a year if there is a good reason and still keep Drupal 10 LTS support.

@Berdir 8.x-4.0-beta6 (next beta) will be without D9 support. Did I understand you correctly?

Yes, the trickier question is which version we _do_ support then exactly. as mentioned, IMHO 10.2 is sufficient to use the new attributes discovery, that seems like the biggest thing.

10.2 will suit me

Thanks all !

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