Die erste zu treffende Entscheidung ist die, ob Sie einen (stabilen) Produktions-Release oder aber einen Entwicklungs-Release verwenden wollen. Im MySQL-Entwicklungsprozess koexistieren mehrere Release-Serien miteinander, die sich alle durch ihren Grad der Ausgereiftheit voneinander unterscheiden:
MySQL 5.1 ist die nächste Entwicklungs-Release-Serie. In ihr werden neue Funktionen implementiert. Alpha-Releases sind derzeit verfügbar und erlauben umfassende Tests durch interessierte Benutzer.
MySQL 5.0 ist die aktuelle Release-Serie für Produktionsumgebungen. Neue Releases erscheinen nur bei Vorhandensein von Bugfixes; neue Funktionalitäten werden nicht ergänzt, da sie die Stabilität beeinträchtigen könnten.
MySQL 4.1 ist die vorherige Release-Serie für Produktionsumgebungen. Neue Releases erscheinen hier, wenn kritische Bugs und Sicherheitslücken behoben werden. Bei dieser Serie werden keine wesentlichen neuen Funktionen mehr hinzugefügt.
MySQL 4.0 und 3.23 sind die alten stabilen Release-Serien für Produktionsumgebungen. Diese Versionen sind nun stillgelegt, d. h., neue Releases erscheinen nur, wenn extrem kritische, vorzugsweise sicherheitsrelevante Bugs behoben werden.
Wir halten ein endgültiges Einfrieren von Codes nicht für machbar, da dies Bugfixes und andere Fehlerbereinigungen, die erforderlich sind, unmöglich machen würde. Das von uns bevorzugte „Teileinfrieren“ erlaubt uns das Ergänzen von Kleinigkeiten, die sich nicht auf die Einsatzfähigkeit eines Produktions-Releases auswirken sollten. Natürlich pflanzen sich wesentliche Bugfixes in früheren Serien auch auf ihre jeweiligen Nachfolger fort.
Wenn Sie MySQL zum ersten Mal verwenden oder es auf ein System portieren wollen, für das keine binäre Distribution verfügbar ist, empfehlen wir Ihnen normalerweise, die Produktions-Release-Serie zu verwenden. Derzeit ist dies MySQL 5.0. Alle MySQL-Releases – auch die der Entwicklungsserie – werden vor der Veröffentlichung mit den MySQL-Benchmarks und der umfangreichen Testsuite überprüft.
Wenn Sie ein älteres System verwenden und ein Upgrade durchzuführen beabsichtigen, gleichzeitig aber verhindern wollen, dass es während der Aktualisierung zu Problemen kommt, dann sollten Sie auf die aktuelle Version derselben Release-Serie aktualisieren, die Sie bereits verwenden (hierbei ist nur der letzte Teil der Versionsnummer höher als bei der von Ihnen verwendeten Version). Wir haben lediglich versucht, kritische Bugs zu beheben und kleine, relativ „sichere“ Änderungen an dieser Version vorzunehmen.
Wenn Sie neue Funktionen verwenden wollen, die nicht in der Produktions-Release-Serie vorhanden sind, können Sie sich auch für eine Version aus der Entwicklungsserie entscheiden. Beachten Sie, dass die Entwicklungs-Releases nicht so stabil sind wie die Produktions-Releases.
Wollen Sie die allerneuesten Quellcodes mit allen aktuellen Patches und Bugfixes einsetzen, dann können Sie eines unserer BitKeeper-Repositorys verwenden. Dies sind nicht „Releases“ im eigentlichen Sinne, sondern Vorabversionen des Codes, auf dem zukünftige Releases basieren werden.
Das MySQL-Benennungsschema verwendet Release-Namen, die aus drei Zahlen und einem Suffix bestehen. Dies kann etwa so aussehen: mysql-5.0.12-beta. Die Zahlen im Release-Namen sind wie folgt zu interpretieren:
Die erste Zahl (5) ist die Hauptversion und beschreibt das Dateiformat. Alle MySQL 5-Releases haben das gleiche Dateiformat.
Die zweite Zahl (0) ist der Release-Level. Zusammengefasst bilden Hauptversion und Release-Level die Nummer der Release-Serie.
Die dritte Zahl (12) ist die Versionsnummer innerhalb der Release-Serie. Diese wird bei jedem neuen Release um den Wert 1 erhöht. In der Regel sollten Sie immer die neueste Version in der von Ihnen gewählten Serie verwenden.
Bei kleineren Updates wird jeweils die letzte Zahl im Versions-String hochgezählt. Liegen wesentliche Neuerungen bei den Merkmalen oder kleinere Inkompatibilitäten mit vorherigen Versionen vor, dann wird die zweite Zahl im Versions-String hochgezählt. Ändert sich schließlich das Dateiformat, dann wird die erste Zahl erhöht.
Release-Namen enthalten auch ein Suffix, welches die Stabilitätsstufe für den Release angibt. Releases innerhalb einer Serie durchschritten eine bestimmte Abfolge von Suffixen, die jeweils anzeigen, wie sich die Stabilität erhöht. Mögliche Suffixe sind die folgenden:
alpha zeigt an, dass der Release neue Funktionen enthält, die noch nicht umfassend getestet wurden. Bekannte Bugs sollten im Abschnitt „News“ dokumentiert sein. Siehe auch Anhang D, MySQL-Änderungsverlauf (Change History). Die meisten Alpha-Releases implementieren neue Befehle und Erweiterungen. Die aktive Entwicklung, die auch umfassende Änderungen am Code beinhalten kann, erfolgt in der Alphaphase. Allerdings werden vor der Veröffentlichung eines Releases Tests durchgeführt.
beta bedeutet, dass der Release funktionsseitig abgeschlossen ist und der gesamte neue Code getestet wurde. Es werden keine wesentlichen neuen Funktionen und Merkmale mehr hinzugefügt. Es sollten auch keine kritischen Bugs mehr vorhanden sein. Eine Version wechselt vom Alpha- in den Betastatus, wenn mindestens einen Monat lang keine schweren Bugs mehr für die Alphaversion gemeldet wurden und wir nicht beabsichtigen, neue Merkmale hinzuzufügen, die die Zuverlässigkeit der zuvor implementierten Funktionen beeinträchtigen könnten.
Bei zukünftigen Beta-, Release-Candidate- oder Produktions-Releases erfolgen keine Änderungen mehr an APIs, extern sichtbaren Strukturen und Spalten für SQL-Anweisungen.
rc ist ein Release-Candidate, d. h. eine Betaversion, die bereits seit einiger Zeit verfügbar ist und offensichtlich stabil arbeitet. Es werden nur noch kleinere Fehlerkorrekturen vorgenommen (deswegen entspricht der Release-Candidate auch dem, was man früher als Gamma-Release bezeichnete).
Ist kein Suffix vorhanden, dann bedeutet dies, dass die Version bereits seit einiger Zeit an vielen verschiedenen Standorten läuft, ohne dass kritische nachvollziehbare Bugs gemeldet wurden (Ausnahme: plattformspezifische Bugs). Bei solchen Releases werden nur kritische Bugfixes implementiert. Eine solche Version nennen wir Produktions-Release (stabilen Release) oder auch „GA-Release“ (General Availability, allgemeine Verfügbarkeit).
MySQL verwendet ein Benennungsschema, welches sich geringfügig von dem anderer Produkte unterscheidet. In der Regel können Sie problemlos jede Version einsetzen, die bereits seit ein paar Wochen verfügbar ist, ohne durch eine neue Version innerhalb derselben Release-Serie ersetzt worden zu sein.
Alle MySQL-Releases werden mit unseren Standardtests und Benchmarks überprüft, damit gewährleistet ist, dass ihr Einsatz relativ sicher ist. Da die Standardtests im Laufe der Zeit so erweitert werden, dass alle zuvor gefundenen Bugs berücksichtigt werden, wird unsere Testsuite immer besser.
Alle Releases wurden zumindest mit den folgenden Tools getestet:
Einer internen Testsuite.
Das Verzeichnis mysql-test
enthält
ein umfangreiches Set mit Testfällen. Wir führen diese
Tests an praktisch jeder Serverbinärdatei durch. Weitere
Informationen zur Testsuite finden Sie in
Abschnitt 26.1.2, „MySQL-Testsystem“.
MySQL-Benchmarks.
Diese Reihe führt eine Anzahl gängiger Abfragen aus. Ferner ermöglicht sie zu bestimmen, ob der letzte Optimierungsstapel den Code tatsächlich beschleunigt hat. Siehe auch Abschnitt 7.1.4, „Die MySQL-Benchmark-Reihe“.
Crash-Me
-Test.
Dieser Test versucht zu ermitteln, welche Funktionen die Datenbank unterstützt und welche Fähigkeiten und Einschränkungen vorhanden sind. Siehe auch Abschnitt 7.1.4, „Die MySQL-Benchmark-Reihe“.
Wir testen außerdem die neueste MySQL-Version immer auf zumindest einem System in unserer internen Produktionsumgebung. Dabei stehen uns mehr als 100 Gbyte Daten zum Arbeiten zur Verfügung.
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.