Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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!

there's a lot of questions about svn here but they've only confused me further :-z

somehow I've managed so far but I need to know the proper procedure for updating my plugin to the new version with regards to committing the trunk and making a tags directory.

This is what I've been doing so far.

  1. code the plugin updates on my local until I'm happy with it
  2. copy over all the files inside my local plugin folder to the /trunk/ (the plugin and readme file have updated version numbers)
  3. commit the trunk directory
  4. 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?

also, about version numbers...

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 ?

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)

another question,

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?

share|improve this question
1  
no reason to be embarrassed, I also had problems about a month ago and you have actually come a lot further than I :) @EAMann describes the entire procedure really well, incl screenshots, on this thread: wordpress.stackexchange.com/questions/16951/… –  Piet Jun 12 '11 at 12:05

1 Answer 1

up vote 8 down vote accepted

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.

  1. code the plugin updates on my local until I'm happy with it
  2. copy over all the files inside my local plugin folder to the /trunk/ (the plugin and readme file have updated version numbers)
  3. commit the trunk directory
  4. 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?

Almost ...

The steps you should be following:

  1. Code the plugin updates locally until you're happy with it
  2. Increment the "stable" tag in your readme.txt file to match the new version number
  3. Copy your local updates into the /trunk directory of the local plugin folder
  4. Commit the entire plugin to save the changes to /trunk to the repository
  5. 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)
  6. 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 readme.txt, commit /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/

share|improve this answer
    
that answer there is the awesome sauce version. :) thanks! –  CommentLuv Nov 2 '11 at 10:04
    
Great answer. One small edit though: When you say never change something that is tagged, that is almost true. Say you make a typo in your readme itself, there is no need to do a maintenance release just to fix it. Was chatting in #wordpress-meta today with one of the lead devs, who mentioned it's okay to just edit your tagged version, as long as it's just the readme.txt file. No others. In general though, yes, stay away from editing your tagged files. –  AndyM May 5 at 20:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.