Over the weekend, it occurred to me that functional problems are also being caused by programmers making the same old mistakes.
This thought was triggered by complaints that iTunes 10 (released late last week) breaks Apple's own Automator support as well as many third-party AppleScripts.
The problem, it turns out is not that version 10 does anything differently to its recent predecessors, but that the programmers who created the Automator actions and AppleScripts didn't know how to test for the version number of the application they were supposed to be supporting.
Well-written scripts and actions will check the version number of the host software in case someone tries to use them with an old version that doesn't include an essential feature. For example, the Add Songs to Playlist action checks that iTunes is no older than version 4.6.
The problem is that version numbers aren't actually numbers.
That seemingly contradictory statement is explained on page 2.
If an essential feature debuted in other than a major version, eg in version 9.2, the basic technique remains the same except that the second part of the number must be included in the process.
So why do I describe blindly checking version numbers as one of the same old mistakes? Because we've seen it - or at least a variation of it -before.
Back in mid 2007, Apple released the Mac OS X 10.4.10 update and a similar problem occurred, just at the other end of the version number. Some software (eg Microsoft's Silverlight installer, but I'm sure there were other examples) bodged the comparison and decided that 10.4.10 was older than 10.4.6 or whatever subversion really was required.
So how could this sort of problem be avoided? Heckman's suggestion of training would clearly help. If you've been taught how to compare version numbers reliably, you'll probably get it right.
But is this really something programmers should be worrying about? Wouldn't is make more sense to have a platform-wide function to compare version numbers that's easily accessible everywhere including AppleScript? Even then, some assumptions might be necessary (who knows what a demented programmer might decide to put in a version number string!), and that could lead to unexpected results.
Version number comparison isn't an isolated problem - please read on.
Even if Mac developers could once reasonably assume that Apple's own version numbers were amenable to simple string comparisons, that era ended in 2007. I can understand why individuals might get this wrong if they create AppleScripts essentially to meet their own requirements and later apply a little polish before releasing them to the world, but that doesn't provide an excuse for the Apple employees or contractors who are presumably responsible for the Automator actions for iTunes.
Automator and iTunes both date back to before 2007, so I am inclined to give a break to whoever originally created the actions. But this issue - along with the recently discovered '_Marshaled_pUnk' vulnerability in the QuickTime ActiveX plugin for Windows and the ongoing discovery of security-related overflow bugs in Apple's software - suggests there may be a lack of effective code reviews at Apple.