-
Notifications
You must be signed in to change notification settings - Fork 153
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
Keep the requirements at PHP 5.6 and WP 4.6 until we have a practical reason #641
base: master
Are you sure you want to change the base?
Conversation
@@ -29,6 +29,10 @@ Here is a list of action and filter hooks provided by the plugin: | |||
- `two_factor_user_authenticated` action which receives the logged in `WP_User` object as the first argument for determining the logged in user right after the authentication workflow. | |||
- `two_factor_token_ttl` filter overrides the time interval in seconds that an email token is considered after generation. Accepts the time in seconds as the first argument and the ID of the `WP_User` object being authenticated. | |||
|
|||
= PHP and WordPress Version Support = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- Keep this in sync with the next version up until 1.0.0. --> | ||
= 0.10.0 = | ||
|
||
From version 1.0.0, this plugin will support WordPress versions up to one year old and the minimum PHP version they require. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use the built-in WP plugin upgrade notice UI to inform users about the upcoming change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The majority of users will never see such a message, whether it be in the Changelog, Description, or Upgrade Notice (which is seen only on the Dashboard -> Updates page)
I don't personally support this, as there's no reasoning given to retain it. Please ensure that the testing pipeline is updated inline with this, but please keep a maintainable test runner. That's one of the main reasons for the increase, the inability to test with ancient versions. So if you're looking at it from a practical point of view; AFAICT no-one tests the plugin with old PHP / WPs, and I definately do not care about them. Practically so few of them will update. If you're looking at it from a usage point of view, I think it makes sense to follow Core's "Less than 5% usage is time to move on from it" which per #640 (comment) we're well past. Duplicating the relevant part here:
I can support this, although I'd prefer a much more aggressive support deprecation. My reasoning is that WordPress.org plugins usage data suggests that the majority of plugin users run up-to-date WordPress (likely thanks to hosts and core auto-updates) and outdated plugins. It's much more rare for a recently updated plugin to be used on an older site. |
This matches my general preference and one in which we've mostly put in place at 10up (though we tend to use WP-2 so two versions back and not just 1). |
What?
Reverts #625.
Why?
Although we want users to upgrade their PHP and WP, the plugin code currently supports PHP 5.6+ and WP 4.6 so we keep those requirements until we've given plenty of notice that version 1.0.0 of this plugin will no longer support anything below 7.4 and a year old WP core.
How?
Testing Instructions
Screenshots or screencast
Changelog Entry