Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump minimum required WordPress version to 6.6 #1682

Open
mukeshpanchal27 opened this issue Nov 20, 2024 · 7 comments · May be fixed by #1683
Open

Bump minimum required WordPress version to 6.6 #1682

mukeshpanchal27 opened this issue Nov 20, 2024 · 7 comments · May be fixed by #1683
Assignees
Labels
Infrastructure Issues for the overall performance plugin infrastructure [Type] Enhancement A suggestion for improvement of an existing feature

Comments

@mukeshpanchal27
Copy link
Member

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.

@mukeshpanchal27 mukeshpanchal27 added [Type] Enhancement A suggestion for improvement of an existing feature Infrastructure Issues for the overall performance plugin infrastructure labels Nov 20, 2024
@mukeshpanchal27 mukeshpanchal27 self-assigned this Nov 20, 2024
@github-project-automation github-project-automation bot moved this to Not Started/Backlog 📆 in WP Performance 2024 Nov 20, 2024
@mukeshpanchal27 mukeshpanchal27 moved this from Not Started/Backlog 📆 to In Progress 🚧 in WP Performance 2024 Nov 20, 2024
@mukeshpanchal27 mukeshpanchal27 moved this from In Progress 🚧 to Code Review 👀 in WP Performance 2024 Nov 20, 2024
@felixarntz
Copy link
Member

@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
Copy link
Member

westonruter commented Nov 20, 2024

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

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
Copy link
Member

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

@felixarntz
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

@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
Copy link
Member

felixarntz commented Nov 21, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Issues for the overall performance plugin infrastructure [Type] Enhancement A suggestion for improvement of an existing feature
Projects
Status: Code Review 👀
Development

Successfully merging a pull request may close this issue.

3 participants