Implement support for annotating certain plugins as experimental#1111
Implement support for annotating certain plugins as experimental#1111felixarntz merged 5 commits intorelease/3.0.0from
Conversation
felixarntz
added
[Type] Enhancement
felixarntz
requested review from
joemcgill,
mukeshpanchal27,
swissspidy,
thelovekesh and
westonruter
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Note for reviewers: I have opened this against If there's substantial feedback or further discussion required that means this can't land in 3.0.0, we can adjust the base branch and change it to target 3.1.0. |
There was a problem hiding this comment.
Another note: The CI failures in https://github.com/WordPress/performance/actions/runs/8547642712/job/23420147133?pr=1111 are unrelated, so we should fix them separately. See #1012.
mukeshpanchal27
left a comment
mukeshpanchal27
left a comment
There was a problem hiding this comment.
Thanks @felixarntz for the PR. It look good to me.
The PR is #1112 not 1012 |
|
I was hoping we can just mark them as experimental based on the version number (i.e. < 1.0.0 is experimental), but turns out Auto Sizes is already at 1.0.0 🙃 |
Yeah, we probably need an extra flag. It's also worth considering that in certain edge-cases we may even want to designate plugins as experimental again when they weren't before. Potentially this could apply to Dominant Color Images / Image Placeholders as right now nobody is really exploring a path forward or maintaining it, and it received a lot of concerns/pushback when initially proposed in a Make Core post. Just thinking out loud, I'm not saying we should do that. But probably a flag is helpful for several reasons. Could you (or someone else) please give another review to this PR? Since #1112 was now merged into this, the CI failures are resolved, so this is good for a review. |
| * @return array<string, string> Map of plugin slug and the version constant used. | ||
| * @return array Associative array of $plugin_slug => $plugin_data pairs. | ||
| */ | ||
| function perflab_get_standalone_plugin_version_constants() { |
There was a problem hiding this comment.
Note for reviewers: This function is simply moved down (see bottom of the file), it's not being replaced as potentially the diff here may suggest.
…s are explicitly recommended, some are experimental).
westonruter
left a comment
westonruter
left a comment
There was a problem hiding this comment.
LGTM but with a suggestion to formalize the description of a return value with an array shape for static analysis.
Co-authored-by: Weston Ruter <[email protected]>
4 participants
Summary
Fixes #1045
Relevant technical choices
perflab_get_standalone_plugin_data()function so that all standalone plugin data can be defined in one place.auto-sizesandembed-optimizeras experimental for now.auto-sizesbecause its browser behavior isn't really available yet,embed-optimizerbecause it's very new and a0.xversion.See screenshot of what this would look like based on the PR implementation:
