Windows ConfidentialWie aus Betaversionen Release Candidates wurden
Raymond Chen
In den frühen Tagen von Windows® folgten Vorabversionen des Produkts mehr oder weniger einem Standardablauf. Zunächst gab es die Alphaversionen, die intern verwendet und möglicherweise mit Softwareentwicklungspartnern außerhalb des Windows-Produktteams gemeinsam verwendet wurden.
Den Alphaversionen folgen natürlicherweise Betaversionen, die an ein etwas breiteres Publikum gesendet werden. Ein Hauptunterschied zwischen Alpha- und Betaversionsbenutzern besteht darin, dass Betaversionen Personen einbeziehen, die keine Softwareentwickler sind, wie Endbenutzer, die Vorabsoftware testen möchten, und Unternehmen, die einen Vorsprung bei der Bewertung des Betriebssystems wünschen, um die Kompatibilität des neuen Produkts nicht nur mit ihren wichtigen betriebsinternen Anwendungen zu testen, sondern auch mit ihrem Unternehmensnetzwerk, mit Standardhardwarekonfigurationen und Systemverwaltungstools.
Schließlich gab es Release Candidates. Dabei handelte es sich, wie der Name schon sagt, um Versionen des Codes, die Kandidaten für eine endgültige Veröffentlichung waren. Anders gesagt: „Wenn alles gut geht, liefern wir dieses Prachtstück.“ Falls ein schwerwiegender Fehler gefunden wurde, der diese Erwartung zunichte machte, wurde sofort nach Behebung dieses Fehlers ein neuer Release Candidate-Build erstellt, und der Testzyklus wurde neu gestartet. Windows 95 wurde in Form seines sechsten Release Candidate ausgeliefert.
Mir kam zu Ohren, dass die Leute von Windows NT® demselben Versionsbenennungsschema folgten, aber dabei auf ein Problem stießen: Unternehmen machten sich nicht die Mühe, ihre wichtigen Anwendungen mit den Betaversionen von Windows NT zu testen. Die Logik dahinter sah für gewöhnlich folgendermaßen aus: „Warum die Mühe machen? Es ist nur eine Betaversion. Betaversionen sind für Computerfreaks. Es wird sowieso alles anders sein in der endgültigen Version. Jegliche Tests, die wir jetzt durchführen, wären verschwendete Zeit.“
Ähnlich kümmerten sich Softwareunternehmen nicht um Probleme, die während der Betatests von Windows NT auftraten. „Wir unterstützen keine Betabetriebssysteme“, war die gängige Antwort.
Diese Unternehmen begannen mit ernsthaften Tests, nachdem die eigentlichen Release Candidate-Builds auf den Markt kamen, und sie fanden unvermeidlicherweise einen Haufen Probleme. Bei einigen handelte es sich um Probleme, die die Unternehmen selbst beheben konnten, während andere Probleme darauf zurückzuführen waren, dass Windows NT nicht „kompatibel genug“ mit der früheren Version des Betriebssystem war. Es gab kleinere Probleme mit der Art und Weise, in der ein bestimmtes Projektfeature funktionierte, und einige davon konnten manchmal innerhalb kurzer Zeit gelöst werden. Einige Probleme waren jedoch so schwerwiegend, dass die Veröffentlichung des Produkts verschoben werden musste, damit das Team das Problem lösen konnte.
Diese Release Candidate-Builds führten außerdem zu einer Reihe von Vorschlägen. Wir erhielten Feedback wie z. B. „Wir denken, die Benutzeroberfläche würde besser aussehen, wenn Sie die Schaltflächen so anordnen“ und „ein Neuformulieren dieser Nachricht würde unsere Mitarbeiter weniger verwirren“. Dies wären großartige Vorschläge gewesen, wenn sie während der Betaphase gemacht worden wären, jedoch zu dem Zeitpunkt, an dem der erste Release Candidate ausgeliefert wird, ist es viel zu spät, Änderungen am Design der Benutzeroberfläche vorzunehmen. Die Dokumentation und die Hilfedateien wurden bereits geschrieben, das Produkt wurde in dutzende von Sprachen übersetzt, und die Bildschirmfotos für das Handbuch und die Produktverpackung waren bereits entworfen, abgestimmt und gedruckt worden. All diese Arbeit wird nicht einfach über den Haufen geworfen und noch einmal durchgeführt, nur um eine Schaltfläche zu verschieben.
Ich erinnere mich an eine Besprechung während der Ära von Windows XP, während der eine dieser Last Minute-Änderungen debattiert wurde. Die vorgeschlagene Änderung hätte erfordert, dass eine 20 KB-Hilfedatei verändert würde, damit die Anweisungen der neuen Benutzeroberfläche entsprächen. Der Lokalisierungs- und Übersetzungsexperte informierte uns, dass ein Neuübersetzen der geänderten Hilfedatei in der extrem knappen zur Verfügung stehenden Zeit hunderttausende Dollar kosten würde.
Um der Auffassung entgegenzuwirken, dass Betaversionen nicht zählen, machte das Windows NT-Team Gebrauch von einer Bezeichnungsinflation. Es gibt nach wie vor Betaversionen, die späten Betaversionen jedoch – wenn noch Zeit ist (jedoch nicht viel), etwas Feinabstimmung durchzuführen – werden nun Release Candidates genannt, und was früher als Release Candidates galt, sind nun Escrowbuilds. Der Begriff „Escrow“ (Geld oder ein Objekt, das von einem Dritten treuhänderisch verwaltet und nur bei Erfüllung bestimmter Voraussetzungen freigegeben wird) ist gut geeignet, den wirklichen Status des Builds zu vermitteln: „Es ist abgeschlossen, und wir werden es nur anrühren, wenn es sich um einen echten Notfall handelt.“
Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch (Addison-Wesley, 2007) mit der Geschichte von Windows und mit der Win32-Programmierung.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.