Bump minimum required WordPress version to 6.6

[mukeshpanchal27]

For context on why I'm opening this issue, please see https://make.wordpress.org/performance/handbook/performance-lab/version-support-policy/. Specifically, the following:

The Performance Lab plugin commits to supporting the latest stable version of WordPress core.

[felixarntz]

@mukeshpanchal27 Curious why we would want to bump the requirement at this point?

We commit to supporting the latest version, but that doesn't mean we need to only support the latest version. I think we should bump the requirement when it makes sense. For example, if there's a new feature in the Core version that we want to have available, that's a good reason, or when maintenance of supporting a certain version becomes a burden. But I don't think we should do it arbitrarily.

If anything, I'd argue maybe we wait a bit longer and eventually can bump the required version to 6.7, since that is the latest stable version already. So I'm also not sure why we would want to bump it to 6.6 instead of 6.7. But that's just a secondary concern.

[westonruter]

I think bumping it makes sense, especially to 6.7. We're not testing versions prior to latest in our automated tests: (wrong)

performance/.github/workflows/php-test-plugins.yml

Lines 43 to 53 in 20a038f

	matrix:
	php: ['8.1', '8.0', '7.4', '7.3', '7.2']
	wp: [ 'latest' ]
	coverage: [false]
	include:
	- php: '7.4'
	wp: '6.5'
	- php: '8.3'
	wp: 'trunk'
	- php: '8.2'
	wp: 'latest'

Also, if we're not explicitly doing QA on older versions, then users of the plugin on older versions of WP would be getting false promises of it working. We could break something without being aware.

We also don't want to facilitate users to stick on old versions of WP.

[westonruter]

Sorry, I completely missed seeing wp: '6.5' in the build matrix.

[felixarntz]

We don't want to encourage people to stay on old versions, but I don't think we're doing that. But we also don't need to "artificially" limit people from getting a new version of our plugins because they haven't updated to the latest WordPress release yet. That's probably worse than them not having updated Core, but at least being on the latest versions of our plugins.

Again, I'm not arguing in any way to change our support policy, it makes sense as is. But if there's no real downside for us in still supporting 1-2 previous versions, it doesn't make sense to me to bump the requirement just because we can.

[felixarntz]

On another note, bumping to 6.7 would make a lot more sense to me than to 6.6 because if we do that, there are actual benefits: We would be able to remove checks like function_exists( 'wp_sizes_attribute_includes_valid_auto' ), and the entire auto-sizes functionality since it's then guaranteed in Core.

So going back to the above, this kind of rationale we should always have if we want to bump a version. Granted, this is not a huge win, but it's still a win.

Since 6.7 is still super new, I'd still be inclined to say let's wait maybe for another month before making that change. But then I'd definitely be in favor.

[mukeshpanchal27]

@mukeshpanchal27 Curious why we would want to bump the requirement at this point?

I followed our current policy, which supports the latest version. Based on the discussion above, we should consider updating our policy to avoid confusion in the future.

[felixarntz]

@mukeshpanchal27 Curious why we would want to bump the requirement at this point?

I followed our current policy, which supports the latest version. Based on the discussion above, we should consider updating our policy to avoid confusion in the future.

Note that the policy does not state that we should only support the latest version. It only states that the team commits to supporting the latest version. That does not mean that we must only support the latest version. It means we could support previous versions too, but there's no guarantee for that. So I think that's correct.