Recently I tried to update my plugin to WP server.
The update to trunk folder went fine, but when I created a folder with a new version under tags folder and tried to upload it, only the immediate children files of this folder where uploaded successfully and the sub folders weren’t.
Eventually I figured out that the svn info file “thinks” that this sub folder already exists in the server even though it doesn’t, so I used Tortoise delete function and a few times and then added it and click commit. Finally after more than an hour of trial and error, I succeeded.
That was really frustrating because I know that people already received an update notification and some of them might have updated and received an error message that crashed their admin!
My questions are:
- Should I switch to working with command line instead of Tortoise? will it be safer?
- Is there a way to postpone the version update notification until I confirm somehow that I have completed the upload of the new version successfully?
Question 1: Should I switch to working with command line instead of Tortoise? will it be safer?
No, tortoise SVN does everything you need to do pretty well and without the need for you to learn every command line command. I’ve used it plenty of time, and I never had problems that were related to it, the problems were related to me using it 😉
BTW: Tortoise SVN contains the same code under the hood as the command line client, so both are exactly the same kind of safe. But you can download SVN for the commandline as well and even use both in parallel. But that’s not really something helpful for you, I guess. Just take Tortoise SVN as it is much easier to use.
I think you missed to svn-add the subdirectories. As long as you do not add those, they won’t get committed. It’s just that they were not under version control so SVN did not know that those should be committed.
Question 2: Is there a way to postpone the version update notification until I confirm somehow that I have completed the upload of the new version successfully?
Normally there is no need to do so. Only for the very first version, the ZIP package is created automatically by the wordpress website. For any additional version, you need to tag a release before the new plugin.zip is generated.
So as long as you do not tag your next release, nobody will get notified about the new version.
Further Question 1: So basically I can upload the new version without incrementing the version in the main plugin file and the readme file and only when I see it the update was successful, I can update only those 2 files after incrementing the version.
That’s soemthing you can do as well. In the end you should update the readme.txt and the plugin file headers otherwise this won’t be user-friendly might create a wrong view.
I normally change those two files in my development trunk directly directly after I tagged the last release, so not at the end. This works very well for me. So this is quite the opposite then in your question.
Just tag for your next release and you are fine. The tagging will signal wordpress.org plugin repository that a new version is available. Until then, only the development version get’s upated after each commit if I remember that right. And that’s nothing problematic as it is the development version. Those normally do not get downloaded, and they are not announced with the update feature.
This should answer your other question as well: Update notifications aren’t send out unless you tag.
Further Question 2: Creating a branch is for major versions, right?
No, that’s unrelated. You can create a tagged version as a minor or bugfix release as well. The following principle is common:
This is the first major release.
This is a feature release within the first major release.
This is the first bugfix release for the first feature release in your first major release.
This is common. The wordpress.org plugin repository does not support this out of the box very well, it’s just counting up, regardless which position this is.
To fine-tune that, you can tag (within plugin headers) your plugin as being stable:
So on wordpress.org you can have one stable version only but next to that you can have countless of other versions as well. And you can (and should) tag them, too. Probably each time you fixed a bug or added a feature.
So you normally count up release numbers. If you’re creating a beta, you can add that behind, which is normally understood by users pretty well:
This works as well. For a real life example you can take a look on the table at the bottom ob this plugin page on my homepage.
That’s a wordpress plugin that is also released on wordpress.org. The according line-up can be found here: http://wordpress.org/extend/plugins/better-http-redirects/download/