For the purpose of this exercise, I’m going to update the Tested up to value for my Stop Emails plugin, without creating a new release.
Get Your Subversion Repository URL
This URL is available on the Developers tab of your plugin on wordpress.org in the Subversion Repository link. In my case, the url is http://plugins.svn.wordpress.org/stop-emails/.
Checkout a Local Copy of the Subversion Repo
svn co http://plugins.svn.wordpress.org/stop-emails/
Navigate into your plugin directory with something like
cd stop-emails
Update Your “Tested up to” Value
You should updated your “Tested up to” value in your latest tagged release. Look in tags/ and find the latest version, in my case 1.2.1. If you want to edit this from the command line, you can use
nano tags/1.2.1/readme.txt
You can review the change by using svn diff
Push the changes back to wordpress.org
You then check-in your changes and include a message of the change.
svn ci -m "Tested up to bumped to 5.9 in tagged release 1.2.1"
My Block X-ray Attributes Plugin
In order to make my life easier, I’ve made these notes for updating my Block X-ray Attributes plugin.
svn co http://plugins.svn.wordpress.org/block-xray-attributes/
cd block-xray-attributes
nano tags/1.2.0/README.md
svn diff
svn ci -m "Tested up to bumped to 6.3 in tagged release 1.2.0"
My Modify Comment Parent Plugin (Trunk Based)
In order to make my life easier, I’ve made these notes for updating my Modify Comment Parent plugin.
Note: While in my other two plugins I have my code in the tags folders, where the code for all my previous versions is available in the SVN repository.
This plugin is different in that I only have code in the trunk folder. I only have the the latest code in the SVN repository (though the development history is all available at https://github.com/salcode/modify-comment-parent).
The only impact of using trunk instead of a folder in tags is the path to readme.txt is slightly different.
svn co http://plugins.svn.wordpress.org/modify-comment-parent/
cd modify-comment-parent
nano trunk/readme.txt
svn diff
svn ci -m "Tested up to bumped to 6.3 in trunk"
Why I Wrote this Post
The only time I ever use subversion is for managing my plugin on wordpress.org. Every time I use it, I have to look up how.
For tagged releases (e.g. version 1.2.1) I use a deploy script written by others smarter than I and more well versed in subversion. Creating a tagged release for a bump in the Tested up to value would be overkill.
Photo Credit: WikiMedia Commons
Hi,
Thanks for sharing this “Tested up to” value with us. It will be a great help for me.
Regards,
Hello Sal:
Wordfence security plugin displayed a “changed file warning” after I tried this once with my Quick Mail plugin.
I waited two days for warning to be resolved, before I added a feature and bumped version.
Best wishes,
Mitchell
Thanks for sharing this, Mitchell. It appears you’re not the first to have this experience, Wordfence False Positive Modified File Warning for Akismet.
According to Wordfence
Taken from Wordfence Docs Scan plugin files against repository versions for changes
While I agree that you should never modify your code without increasing your version number, my understanding is the best practice for the WordPress plugin repository is to update the “Tested up to” value while maintaining the same version number. I’d love to see Wordfence whitelist this type of change when scanning plugins (or work with the WordPress plugin repository to update their best practices).
Hello Sal:
Authoritative source agreed with your article:
you don’t need to release a new version — just change the stable version’s readme value.
See: https://make.wordpress.org/plugins/2015/04/21/reminder-please-test-your-plugins-with-4-2/
Unfortunately, clients with admin access see unexpected security warnings.
Best wishes,
Mitchell
Interesting discussion. As a plugin developer, I didn’t realize that changing the readme file without updating the whole plugin would cause an issue.
There are a lot of things to remember before updating a plugin and the first few times I did this I would forget about one of the changes. Now I have a list: update the version in the plugin file header, plus the version number that’s saved in a variable, and then the readme file needs the stable tag updated, plus the changelog and the upgrade notice.
I agree with you Emily, it is always a good idea to have a checklist.
Mark Jaquith had a nice presentation at WordCamp Miami 2016 called Grunt and the Art of Plugin Maintenance that discussed automating this process. As of my writing this comment, it isn’t on WordPress.tv yet but when it is, I recommend checking it out.
Thank you for your support.(:)
I have a small script that automates all this. I should probably open source it.
That sounds really cool. If you do publish it, please let me know.
Thanks for this.
A caveat I experienced was that the change was not reflected in the plugin repository until I also updated the trunk directory.
I almost think that it would make more sense to update trunk and then, since this isn’t a new release, copy that to the tagged version to keep them in sync. But I am not in any way an expert on svn update processes so I’ll let others who are judge such suggestions accordingly.
Peace,
Phil
Hi Phil,
This is the process I’ve used in the past and I’ve always seen the update on my plugin page. Two possibilities come to mind:
1. The value was cached and after a certain amount of time the new value would be displayed. In this scenario, it also seems reasonable the update of the trunk directory cleared the cache.
2. The behind the scenes code of the plugin repository has changed making the trunk directory update necessary.
In either case, I appreciate your comment and I’ll be watching closely the next time I try to update this value. Thanks.
I can see you’ve recently updated the article, and I wanted to say thank you for publishing it – it’s just allowed me to easily bump the tested version number on a plugin that I had access to, whilst the original author was fixing a crashed laptop!