Man sagt natürlich "Mäk Oh Es Zehn Taiger Zehn Vier Zehn".
Für die Technik-Freaks unter Euch:
Es gibt einen technischen Grund, weshalb die Nummerung tatsächlich bestimmten Grenzen unterliegen sollte: Es gibt in Mac OS X einen alten Carbon-Funktionsaufruf, der aus Mac OS übernommen wurde. Diese Funktion liefert einem Programm die Versionsnummer des gerade laufenden Betriebssystems in einem speziellen Code zurück, nämlich als 16-Bit-Zahl, gedeutet als vierstellige Hexadezimalzahl, wobei die ersten beiden Ziffern die Hauptversionsnummer, die dritte Ziffer die Unterversionsnummer und die vierte Ziffer die Unterunterversionsnummer darstellen.
Beispiel: Die Version Mac OS X 10.4.9 wird in Carbon durch die Zahl 4169 codiert, weil diese Zahl im Sechzehnersystem als "1049" dargestellt wird. (C-Programmierer markieren Hexadezimalzahlen mit "0x", also 0x1049.) Mac OS X 10.2.5 hatte den Code 4133, weil dies der Zahl 0x1025 entspricht.
Bei 10.4.10 scheitert das: Das lässt sich in 4 Ziffern nicht mehr unterbringen, es sei denn, man würde die Hexadezimalziffern A bis F zulassen. Das wiederum gibt Probleme, denn viele Programme sind darauf nicht vorbereitet. Auch ist es inkonsistent, denn 0x104A müsste dann besser als 0x0A4A codiert werden, was aber die ganze Sortierung und Vergleichsmöglichkeiten durcheinanderbringt.
Apple wird hier wahrscheinlich die bisherigen Vorschriften aufgeben und kann diese Codierung nicht mehr fortschreiben bis 10.5 (= 4176) herauskommt. Das heißt, Carbon-Programme, die nur diese veraltete Methode der Versionsprüfung verwenden, werden 10.4.9 nicht von 10.4.10 unterscheiden können, da der Code bei 4169 festhängt. Viele Programme verwenden solche Prüfungen, um zu wissen, auf welche Bugs im System sie sich vorbereiten müssen.
