Automatic updates create a new problem for plugin authors. Users no longer have to download and install a plugin, and in the process see what has changed, they now just update it and hope it all works out. My question today is, what should plugin authors do if they know the latest update is liable to break things?
One option is to release an intermediate version. A version which contains a warning message that the next version will have major changes and so users shouldn’t update without thinking things throught first.
Another options if to bundle a previous version of the plugin. The they can either upgrade but ask the user if they want to go back, or alternatively explain the changes and then ask the user if they want to proceed with them.
Lastly, they could simply prepare to field the inevitable support queries and hope enough users read the updates page before going ahead.
I am still trying to decide which option to go for with some changes to one of my plugins.
Do you ugrade without checking the changes? I know I tend to. If so which option do you prefer? or is there something I have missed?
(__)
`
Lothar, you are right. The first thing I looked at was the plugin upgrade code because I had assumed that the actual upgrade command would feature an optional version number so a plugin author could choose to trigger a roll back.
Out of all the options I personally favour including an older version of the plugin which is enabled automatically, but which has an added page for the user to trigger the replacement.
I may be trying this out fairly shortly on my fun with sidebar tabs plugin because I need to change the class based system to an ID based system and I want to change the structure of the html. There could be a fair amount of breakage.
(__)
`
I always test plugin upgrades on a development site before pushing them live, but I don’t think the sites I manage are typical of the kind of people who use the automatic update anyways.
What I mean is that the people who automatically upgrade without checking the code are not likely to have checked the code even without the automatic update, so probably the only thing that has changed with 2.5 is the likelihood that users will upgrade, not their degree of caution.
But to answer your question, if breaking upon upgrade were unavoidable, I think I would check for the existence of the earlier version and then disable the main functionality, with a prominent admin area warning (like Akismet’s “you don’t have an API key” message). Then the user could opt in to the breakage, or (by following a link) re-install the previous version.
(__)
`
I think that the automatic update function is missing one important feature: it should version-control. So if I publish a plugin for WordPress 2.6 this should be checked by the function and it should only update, if my installation is 2.6 or newer. If I still have 2.5.x, it should not update, but give me a message. That would be the only usefull solution.
(__)
`
Apart from the odd moment of weakness I will always try and check out the authors website for notes about changes etc – though sometimes there is no hint of a changelog :(
Personally I wish the upgrade process would pause once it has downloaded the zip file and display the readme file (and / or perhaps a changelog file) – and only resume installation once the file has been scrolled through / read and a button pressed.
Having a link to the readme file of each plugin on the plugin page might also be quite useful, and I think I have seen a plugin that does that (and more) – but I can’t remember the name of it.
(__)
`
I upgrade w/o checking for changes
(__)
`
! correctly,
and the update-function is to bad. The users like the function and upload all files, incl files screenshit and many language-files.
No visits for a update or read the history :(