I guess you could consider elections to be patches keeping the government up to date.

Edit: On the other hand, there are usually two or more competing “patches” that disagree on how to fix the problems, and even what needs to be fixed.

I also ran the main page through the mobile-readiness evaluator at ready.mobi, and noticed that most of the issues it cited with the mobile edition of the site were really simple changes. Some were basics like fixing unbalanced HTML, and others were recommended practices like including a DOCTYPE and making sure that headings were nested properly. So I whipped together a patch for WordPress Mobile Edition 2.1a. (It’s labeled as 2.1.1 in the readme, but it shows up as 2.1a in the list of plugins.)

Changes:

• Add XHTML Mobile 1.2 Doctype.
• Fix unbalanced <small> tag.
• Fix mising <ul> tags around list of recent posts.
• Avoid empty class attribute on comments.
• Add type attribute to style element.
• Change non-standard value attribute on <meta> tag to content attribute.
• Reassign headings so that h1, h2, h3 appear in order.

Download:

wp-mobile-validation.patch [removed, see below]

The patch should be applied to the wp-mobile folder that you place in your themes folder.

Update: This has been completely superseded by more recent versions of the plug-in, which use Carrington Mobile instead.

Last Friday saw the release of PHP 5.2.4, on the Friday before—in the US, anyway—a 3-day weekend. This morning Apache released security updates for all three supported branches of their webserver. And this evening—yes, Friday evening—WordPress 2.2.3 came out.

Which reminds me, I’m going to have to start looking at the betas for WordPress 2.3. I think it’ll be a good time for a redesign. Maybe pick a new theme and tweak that one, maybe try my hand at actually designing one. I wonder if the new tagging system can import Bunny’s Technorati Tags.

It’s also October, the month leading up to Halloween.

I hereby declare today to be Pumpkin Patch Tuesday.

Update: Mozilla’s Josh Aas has carved the perfect pumpkin to go with this declaration.

One problem is the upgrade path. It’s one thing to provide an updater that goes from version N to version N+1. But what if someone doesn’t run the updater until N+2 is available? Or worse, N+3?

Let’s say someone needs to upgrade from version A to version C, skipping version B. There are three approaches I’ve seen to this problem.

• Sequential Updates. Update from A to B, then run the updater again to go from B to C. Simple for the vendor, but a pain for the user. This is the way Microsoft Update works, which is why you need to re-run Windows Update a million times when you set up a new system (rebooting every other time).
• Multiple patches. Provide an extra patch that goes straight from A to C. This is how phpBB provides updates, and I seem to recall it’s the way Apple’s software update works. This is simplest for the user (assuming the updater picks the patch automatically), but can get really complicated once you start adding versions D, F, G, H, and I.
• Fallback. If someone skips a patch, just send them the whole installer. This assumes most users will be keeping up to date, so it’s most useful if the users check regularly or if the system checks automatically. This is the way Firefox’s updater works.

There are hybrid approaches out there. You could provide multiple patches for N+1 and N+2, but fall back to a full update for N+3. You could automate the sequential updates so that the installer grabs the A→B patch and the B→C patch at the same time, installs the first one, then installs the second one. You could even use different approaches for each version. Adobe Reader provides a patch that will update any 7.0.x version to 7.0.5, then another one that updates 7.0.5 to 7.0.7.

There doesn’t seem to be a “right” method, at least not yet. It seems to be a matter of balancing out priorities, and it probably depends heavily on the number of products you need to manage.