[wp-testers] WordPress Automatic Upgrade

[Alex Günsche]

On Thu, 2007-09-13 at 12:58 +0200, Lorenzo wrote:
> Yes but there are betas and nighly just for testing! :D
> Anyway I think it would be always possible to disable it, if WP notice that
> it can't work properly on the host it will be turned off.
> 
> Pheraps implementing that plugin the testing should be more intensive but
> IMHO it's very important for WP and its use. ;)

An automatic upgrade is not only a very sensitive but also a complex
task. It means automatic downloading, deleting/inserting files, running
an upgrade procedure (this being the process in a nutshell). Each of
these steps can fail if the developer has overseen a detail. Of course,
my plugin makes extensive pre-checks, so luckily there were few real
failures so far. By the way, I emphasize backups very much, so people
were luckily always able to restore after a failure. If you make an
upgrading solution a part of the core, many people will assume that it's
absolutely perfect, and omit the tedious task of doing backups.

If the plugin fails, the whole installation can be broken. Let's assume
one of the both plugins is taken into the core, after it has been
thoroughly tested. Let's assume the plugin is at this point 99.9 percent
perfect, which means a failure rate of 0.1 percent. Assuming that
roughly two million WordPress users would be affected with each upgrade,
and assuming that half of them use the plugin once it's in the core,
this would mean that each WP upgrade using the plugin breaks 1000
WordPress installations (YMMV, but you will always end with an
unacceptably high number of broken WP installations). How ever high that
number is, having the plugin in the core means that any failures will be
a business of the core developers, in the sense of maintenance as well
as reputation.

I am very happy that my plugin works flawlessly for the vast majority of
the users. However, in case of doubt, I recommend anybody to do a manual
upgrade where they know what's happening. In fact, the actual purpose of
this plugin was to provide a tool for experienced users who have to
maintain a number of blogs for rather unexperienced ones and who can
look at the code or manually fix things in case anything goes wrong.

By the way: If you have it as plugin, you would also have to make sure
that the plugin upgrades itself, in case there is an unforseen change in
the WP core which the upgrade routine doesn't reflect. Also, you would
have to provide a full-fledged backup/restore solution, so at least a
larger number of users (you'll never catch them all) will do the
backups. And you must make sure that those both tasks also work nearly
perfect.

All the above are things I thought about when people first said that
this plugin should be in the core package. Don't get me wrong, it's a
big honour for a developer when his code is integrated into the core of
such a great and widespread software as WordPress. But the best for the
community of WordPress users is to select plugins themselves, read the
plugins' docs  and other users' feedback and decide then which way to
go. I admit that this is not easy, and it also bears a number of
problems (like users being too lazy or not aware of the necessity of
upgrading). But these cannot be handled with a seemingly "simple"
out-of-the-box solution.

Alex

-- 
Alex Günsche 
Zirona OpenSource-Consulting
Karlsgraben 56
D-52064 Aachen

Tel: +49 241 4758864 0
Fax: +49 241 4758864 1
Web: http://www.zirona.com

-----------------------------------------------------------------------
This e-mail is digitally signed with GPG. If you receive a warning that
the sender/key isn't trustworthy, please import the public key for this
mail address from www.zirona.com/misc/ag.asc or ignore this warning.
-----------------------------------------------------------------------
-- 
Alex Günsche, Zirona OpenSource-Consulting
Blogs: http://www.zirona.com/ | http://www.regularimpressions.net
PubKey for this address: http://www.zirona.com/misc/ag.ml2007.asc