This change should have been mentioned in the changelog.
Bumping major dependency versions like this also probably should come in a major version bump, or maybe minor version, but not a patch.
Since the PHP 7 requirement stems from a single use of the new <=> operator in the function to sort by author, I don’t think it would be unreasonable to simply implement the author sorting with PHP 5 syntax and keep compatibility.
You are right about the changelog – I’ll get that updated.
However, I disagree about when to make the change. It’s not unreasonable to expect most people to be on PHP 7 by now – I’m coding automatically for PHP 7 and I didn’t want to make specific changes just to support an older version of PHP that any decent host wouldn’t be using.
Indeed, by including this in a minor change, any users this affects can continue to use the previous release and won’t (as yet, anyway) be missing any significant changes (carrot, rather than the stick).
As far as the version numbering goes, might I point to your own description of the versioning system you use?
Version 2.4.2 is a z release, which your described versioning method says should contain “urgent bug fixes, security or maintenance changes only”. In fact, it contains a new feature (sorting by author), and thus falls under at least a y release. I would describe the new function as a “minor enhancement”, consistent with your stated versioning system.
Dropping backwards compatibility of any kind is only mentioned in the x version identifier description:
A major change *might* mean it can break backwards compatibility but I strive to not do this, if at all possible. However code “bulk” is equally something I am concerned about so will often provide backwards compatibility for some time before finally phasing it out in a major release.
So it seems that, at least in 2016, you agreed with me that breaking changes like raising the required version of a dependency (WordPress, PHP, etc.) should come with a major version bump. If your versioning system has changed and that post is simply outdated, then I rest my case on this front.
I do, however, think it’s a bit odd to offer such a relatively simple plugin that cannot run under every environment WordPress itself can. Maybe I’m biased. I do steward a Python project that runs on both 2.7 and 3.3+, even though that causes some code headaches, but I put up with them because I think it’s worth supporting users who can’t upgrade yet. And in this case, the overhead to support PHP 5 really isn’t that big. It’s all of a five-line change. (It would be a seven line diff if I used intermediate variables to store the uppercase versions of the strings to compare, but I see no reason to go back and amend the pull request unless you actually want to merge it.)
I do, however, think it’s a bit odd to offer such a relatively simple plugin that cannot run under every environment WordPress itself can.
WordPress is recommended for PHP 7.2 and above (https://wordpress.org/about/requirements/).
And in this case, the overhead to support PHP 5 really isn’t that big. It’s all of a five-line change.
What I’m not going to do is test and re-write to support older versions, which users really shouldn’t be using (and it’s pretty shameful of any host to still be using it). My hosting is on PHP 7, and that’s what I write for. What I am doing, though, is recognising when I do something that’s PHP 7 specific and therefore updating the PHP minimum level on the README to indicate this.
-
This reply was modified 5 years, 9 months ago by
David Artiss.
And, for openness, I have updated my versioning page now to clarify your questions further.
