I'm embarrassed to say that I am a bit clueless on the procedure used to update a plugin via tortoise svn even though my plugin has been on the repository for years and had over 300,000 downloads!
Don't be. SVN can be tricky for a lot of people ... so let's go through things step-by-step ...
This is what I've been doing so far.
- code the plugin updates on my local until I'm happy with it
- copy over all the files inside my local plugin folder to the /trunk/ (the plugin and readme file have updated version numbers)
- commit the trunk directory
- right click the trunk directory and choose create branch/tag and set it to copy to a folder in /tags/ with the name being the version number
Is that correct and in the right order? if not, what is the correct way?
The steps you should be following:
- Code the plugin updates locally until you're happy with it
- Increment the "stable" tag in your
readme.txt file to match the new version number
- Copy your local updates into the
/trunk directory of the local plugin folder
- Commit the entire plugin to save the changes to
/trunk to the repository
- Right click
/trunk and create a new tag, copying into
/tags/X.X.X where x.x.x is the same version in the "stable" tag of
readme.txt (step 2)
- Commit the entire plugin to save the tag
for some reason, I went from version 2.8.1 to 2.81.2 on my last update, does this mean that it wont show as an update available in the dashboards of people that have version 2.81.2 if I change the next version number to 2.9 ?
Bingo. If you committed version 2.81.2 as an update and people actually downloaded that update, they won't see 2.9 when you release it.
how does wordpress determine which is the latest version and if the user should update their version? does it do a version_compare ? that only works with proper php version format doesn't it? eg. 2.9.2 is considered a lower version than 2.81.2 ? (because, as I understand it, version_compare starts at the left and compares higher/lower for each digit so 9 would be considered less than 81)
Exactly. A standard PHP version comparison will see version 2.81.2 as being a newer version than 2.9 because 81 > 9.
I recommend you release a version 3.0 next, then be very careful when versioning in the future to prevent this kind of typo.
if I spot a silly mistake in the code that doesn't really affect the working of the plugin, maybe a typo or an additional image. What do I edit and commit to make any new downloads of the plugin contain the change?
do I have to edit the trunk AND the tag folder and commit both?
If you need to make a minor change, consider it a maintenance release. I typically following this kind of versioning schema:
2 . 1 . 3 . 5
major minor maint build
Build numbers I only ever use internally or for beta releases ... you'll almost never see a build number from me unless I manually email you a file (it's how I can distribute pre-release versions that won't break WordPress updates).
If I notice a bug in a live version, I'll make a quick patch and release a maintenance version. Let's say I've released version 2.2 of a plugin and someone notices I forgot to invoke jQuery in noConflict() mode. I'll do a quick patch and immediately release 2.2.1.
The increment in the version will force WordPress to recognize the update and provide the fix to anyone who's already installed version 2.2.
To release a maintenance version, you need to follow the exact same steps as if you were releasing a full version of the system. So make changes, increment the version in
/trunk, tag, etc.
But once you've tagged something, you never change it again. Think of your
/tags folder as frozen in time. Each version in that folder is a snapshot of your plugin at a specific point in time. You should never change any files in the
/tags folder directly.
If you find yourself thinking it might be a good idea, smack yourself on the back of the head and release a maintenance version instead :-)
As Piet mentioned, I wrote a good set of step-by-step instructions earlier ... but the site seems to have lost my screenshots. Here's another version of the same step-by-step guide with screenshots from Tortoise hosted on my own site: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/