Improvement: "Tested Up To" Plugin Header

[BlaineMoore]

A potential improvement would be to allow a Tested Up To header in the primary plugin file to denote what version of WordPress the latest updates have been tested on. It would not replace the setTestedWpVersion function but would rather provide an alternative method for setting it upon loading the updater class that's already supported in WordPress. By having it in the header of the plugin file, it'd provide a consistent place to specify that information across different plugins without having to search for the function and would be quicker to update when making edits to the plugin. Basically, a quality of life update for developers.

(I do not personally have a need for it, but the same functionality could easily be added for an Update Branch header to augment the setBranch function if one wanted a plugin to always use a Production branch or to easily be able to have separate branches for a plugin for Production and Staging, etc...though for my own personal use case that'd be better served with a defined constant in wp-config.php instead or by looking for a staging subdomain etc.)

I have a branch here that implements the Tested Up To header that I can send a pull request for depending on the questions that you have.

[ryansechrest]

I definitely like this approach, and actually wanted to place the tested up to version in the header, but couldn't find a corresponding plugin header documented, which led me to creating a method instead.

Do you know if this is an official header field, but the documentation is out of date, or would this be a custom header field?

[BlaineMoore]

I think that it's a custom header field but not 100% certain; I have seen it used in multiple plugins, though, so it seemed like a good option.

However, it is an official part of the readme.txt for repository plugins: https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/

[ryansechrest]

OK, got it. At first, I was hesitant to add a custom, undocumented header, because what if WordPress introduces this as an official header at some point, but for something else.

That said, seeing the README, I think this change feels intuitive enough. I'm going to remove the custom method I created for this, because I don't really want to maintain multiple ways of doing things. This will be the way forward.

I'm also going to update the variable names to match the header for consistency.

[BlaineMoore]

I like adding custom headers; the functions have it built in to be able to easily read them and it makes future updates easier by having customizable options in one place, especially in this case where it's a third party script as part of a plugin.