Skip navigation links
2.1.2.5 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden »
Section Navigation      [Toggle]

2.1.2.4. Release-Philosophie: keine bekannten Bugs in Releases

Wir verwenden viel Zeit und Mühe darauf, unsere Releases fehlerfrei zu machen. Bislang haben wir nicht eine einzige MySQL-Version veröffentlicht, die einen bekannten nachvollziehbaren schweren Bug aufwies (ein „schwerer“ Bug ist ein Umstand, der dazu führt, dass MySQL bei normaler Verwendung abstürzt, falsche Antworten für normale Abfragen erzeugt oder ein Sicherheitsproblem aufweist).

Wir haben alle offenen Probleme, Bugs und Streitfragen dokumentiert, die von strukturellen Entscheidungen abhängen. Siehe auch Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

Unser Ziel ist es, alle Bugs zu beheben, die behebbar sind, ohne eine stabile MySQL-Version weniger stabil machen zu müssen. In bestimmten Fällen bedeutet dies, dass wir ein Problem in den Entwicklungsversionen, nicht aber in der stabilen Produktionsversion beheben können. Natürlich dokumentieren wir solche Probleme, damit sie den Benutzern bekannt sind.

Es folgt eine Beschreibung unserer Vorgehensweise:

  • Wir überwachen das Auftreten von Bugs mithilfe unserer Kundensupportliste, der Bugdatenbank unter http://bugs.mysql.com/ und der externen MySQL-Mailinglisten.

  • Alle gemeldeten Bugs für die aktiven Versionen werden in die Bugdatenbank eingegeben.

  • Wenn wir einen Bug beheben, dann versuchen wir immer, einen Testfall dafür zu erstellen und diesen in unser Testsystem einzufügen, damit gewährleistet ist, dass der Bug nie wieder auftreten kann, ohne sofort erkannt zu werden. (Solche Testfälle gibt es für ca. 90 Prozent aller behobenen Bugs.)

  • Wir erstellen Testfälle für alle neuen Funktionen, die wir in MySQL ergänzen.

  • Bevor wir mit der Erstellung eines neuen MySQL-Releases beginnen, stellen wir sicher, dass alle gemeldeten nachvollziehbaren Bugs der betreffenden MySQL-Version (3.23.x, 4.0.x, 4.1.x, 5.0.x, 5.1.x usw.) behoben sind. Wenn ein Fehler aufgrund interner Strukturentscheidungen in MySQL nicht behoben werden kann, wird dies im Handbuch dokumentiert. Siehe auch Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

  • Wir erstellen einen Build für alle Plattformen, für die Binärdistributionen unterstützt werden, und verarbeiten alle mit unserer Testsuite und der Benchmark-Reihe.

  • Schlagen Testsuite oder Benchmark-Reihe bei einer Plattform fehl, dann wird hierfür keine Binärdistribution veröffentlicht. Ist das Problem in einem allgemeinen Fehler im Quellcode begründet, dann beheben wir es und erstellen den Build einschließlich aller Tests auf allen Systemen von Grund auf neu.

  • Erstellungs- und Testvorgänge benötigen etwa eine Woche. Erhalten wir während dieses Zeitraums eine Meldung zu einem schweren Bug (z. B. einem Bug, der einen Speicherauszug verursacht), dann beheben wir das Problem und starten die Erstellung von Neuem.

  • Wenn die Binärdistributionen auf http://dev.mysql.com/ veröffentlicht wurden, senden wir eine Bekanntmachung an die Mailinglisten mysql und announce. Siehe auch Abschnitt 1.7.1, „Die MySQL-Mailinglisten“. Die Bekanntmachung enthält eine Liste aller Änderungen am und aller bekannten Probleme mit dem Release. Der Abschnitt Known Problems (Bekannte Probleme) in den Versionshinweisen wurde bislang nur bei einer Hand voll Releases benötigt.

  • Damit unsere Benutzer möglichst umgehend auf die aktuellsten MySQL-Funktionen zugreifen können, versuchen wir, alle vier bis acht Wochen einen neuen MySQL-Release anzufertigen. Momentaufnahmen des Quellcodes werden täglich erstellt und sind unter http://downloads.mysql.com/snapshots.php verfügbar.

  • Wenn wir trotz aller Bemühungen nach der Freigabe eines Releases die Meldung erhalten, dass ein kritisches Problem für den Build einer bestimmten Plattform vorliegt, dann beheben wir dieses sofort und erstellen einen neuen 'a'-Release für die betreffende Plattform. Weil so viele Leute MySQL benutzen, sind Probleme schnell gefunden und behoben.

  • Unsere Leistungen bei der Erstellung stabiler Releases sind recht gut. Unter den letzten 150 Releases waren es weniger als zehn, für die wir einen neuen Build erstellen mussten. In drei dieser Fälle wurde der Bug von einer fehlerhaften glibc-Bibliothek auf einem unserer Erstellungssysteme verursacht, die ausfindig zu machen uns recht viel Zeit gekostet hat.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.