Recently Nathan Yergler posted what ought to be the preferred way to install and upgrade WordPress:
First, install WordPress from a Subversion checkout; do:
$ svn co http://svn.automattic.com/wordpress/tags/2.6/
instead of downloading the .zip or .tar.gz file. Configure as directed.Then, when a new version is available, log into your webhost and run:
$ svn switch http://svn.automattic.com/wordpress/tags/2.6.1/
from your install directory.
I’ve been doing this for ages and consider installing from and overwriting with tarballs on an ongoing basis just short of insanity. Unfortunately the WordPress Subversion Access page says it is for developers only and doesn’t describe using svn switch to upgrade — indeed, what they describe (which will always obtain the very latest, usually unreleased, code checked in by WordPress developers), really is only appropriate for WordPress developers and testers. The MediaWiki site does a much better job but still doesn’t push revision control as the preferred deployment mechanism.
WordPress and MediaWiki were pioneers several years ago in making web application deployment and even upgrade painless relative to what came before (mostly by automating as much database configuration and schema migration as possible), but it may take a new generation to make deployment from revision control systems (preferably distributed) the norm. WikiTrust sets a good example [Update 20090622: Though not a good example of cool URIs, code instructions moved to new location without forwarding.]:
There are two ways of getting WikiTrust: via Git (recommended), or via tarballs (easier at first, but harder to keep up-to-date).
[…]
Our preferred way to distribute the code is via Git. Git enables you to easily get the latest version of the code, including any bug-fixes. Git also makes it easy for you to contribute to the project (see Contributing to WikiTrust for more information).
As I’ve mentioned several times in passing, such practices will facilitate open web applications and other network services.