Two releases of 1.1.0?

Hi there,

This isn’t an error; the readme updates within v 1.1.0 are deliberate.

When a new version of WordPress is released, it’s necessary to adjust the readme to show the latest “Tested up to” value.

Best practice for WP plugins has been *not* to release a new stable version when you merely update the readme with a new “Tested up to” number: for example, see this WP release announcement for developers:
https://make.www.ads-software.com/plugins/2015/04/21/reminder-please-test-your-plugins-with-4-2/

This will cause issues with plugin checksumming (and e.g. fire off Wordfence alerts re changes to the readme file), but that will affect any plugins that follow this best practice advice, not just Forum Beginner Posts.

If there are any new official guidelines for plugins on this “Tested up to” issue, however, please do let us know and we’ll follow them – cheers!

I think the WordPress core team need to think about this one!

Whilst you’ve followed “best practice”, it leaves the door wide open for abuse of .zip updates of the same version with code changes (not just readme.txt updates). I’ve now counted at least 6 plugins on wordpresss.org that have actually changed code (and one even included new png’s in the .zip!) and kept the same version for the plugin on a subsequent .zip upload.

Even your minor change to readme.txt will never be picked up as an udpate for anyone with an “older” 1.1.0 installed (never mind the plugin checksum issue I’ve mentioned).

Personally, I think the only safe way is to increment the version number for *any* .zip contents change, even if it’s just one line in readme.txt to say it’s been tested on a later WP release. Then www.ads-software.com can simply refuse to upload a .zip file that contains a plugin with the same version as one that’s already uploaded. It will also make sure that everyone who has “1.1.0” has *exactly the same* “1.1.0” as everyone else!

I do see (and partly agree with) your point! I never feel that happy about changing a file in a fixed release.

On the other hand, frequent updates (especially ones that don’t actually provide any functionality benefits or fixes) really irritate some users. Additionally, if you maintain a lot of sites on behalf of clients and do diligent post-update tests, unnecessary plugin version bumps cause a lot of wasted effort. Swings and roundabouts!

Perhaps the best option would be some sort of external mechanism for specifying the tested-up-to (rather than keeping it within the plugin code repository) – but that would be a pretty significant infrastructure change…

Yes, I was going to suggest that too – moving the “Tested up to” info onto the www.ads-software.com site instead of inside the .zip file. Another thing I don’t like about the .zip files is that there’s no rigid file naming scheme for them (e.g. plugin-name-version.zip or something like that) – some .zip filenames have the version numbers, some don’t, some use separators between the plugin name and version and some don’t…

WP-CLI’s new “plugin verify-checksums” has been highly illuminating indeed. I’ve found a site we host that is using a plugin that’s completely undownloadable from www.ads-software.com any more (so no checksums to check!). Another useful feature is to detect if one of our devs has modified plugin code (yes, I found one that been modded – turns out that was the only way to use it – directly hack a line in the plugin PHP code!).