wie Sie Ihre Projekte benennen
- Projektname-7.25-1.0-alpha
- Projektname-7.25-1.0-beta1
- Projektname-7.25-1.0-dev2
- Projektname-7.25-1.0-rc3
- Projektname-7.25-1.0-Stable4
- Projektname-7.25-1.0-instabil5
Best Practices befolgen?
11
Unter Drupal.org finden Sie Namenskonventionen für Releases und weitere Erläuterungen .
Zusammenfassung:
rc = Release Candidate, vom Autor für Produktionsstätten als geeignet erachtet.
rc : Ein Release-Kandidat sollte nur erstellt werden, wenn alle kritischen Fehlerprobleme in der Problemwarteschlange des Projekts behoben sind. Dieses Tag sollte nur verwendet werden, wenn der Entwickler der Ansicht ist, dass das Projekt für die Verwendung an einem Produktionsstandort bereit ist. Es gibt keine offizielle Best Practice dafür, wie lange ein Projekt ein Release-Kandidat sein sollte, bevor eine offizielle .0-Version erstellt wird. Es wird jedoch empfohlen, dass es mindestens einen Monat lang nicht veröffentlicht wird und der Status auf "Bedarfsüberprüfung" gesetzt ist. Wenn etwas (z. B. ein neuer kritischer Fehler gemeldet) es erforderlich macht, in diesem Zeitraum eine neue Version zu erstellen, sollte ein neuer Release-Kandidat erstellt werden, der mindestens einen Monat lang mit dem Status "Bedarfsüberprüfung" bestehen bleibt.
Es ist in Ordnung, ein Modul "rc" mit ausstehenden Problemen mit Funktionsanforderungen zu kennzeichnen. Modulautoren müssen nicht alle Funktionsanforderungen erfüllen, die Benutzer des Modulposts in der Problemwarteschlange stellen.
Hier ist eine Beschreibung der anderen zulässigen Release-Tags:
instabil : Das Projekt befindet sich nicht in einem stabilen Zustand. Es gibt wahrscheinlich zahlreiche nicht behobene Fehler, einschließlich Sicherheitsproblemen. Die API kann ohne vorherige Ankündigung geändert werden. Das Datenbankschema kann sich ändern, ohne hook_update_Nimplementiert zu werden. Verwendung und API sind möglicherweise nicht dokumentiert. Bei der Installation einer neuen instabilen Version wird das Projekt deinstalliert, wodurch alle Daten verloren gehen. Nur für diejenigen, die eine frühe Vorschau des Projekts wünschen. Noch nicht für die gemeinsame Entwicklung geeignet.
Alpha : Die meisten gemeldeten Fehler werden behoben, es können jedoch noch schwerwiegende bekannte Probleme auftreten, einschließlich Sicherheitsproblemen. Das Projekt wird nicht gründlich getestet, daher kann es auch viele unbekannte Fehler geben. Es gibt eine README.txt / README.md, die das Projekt und seine API (falls vorhanden) dokumentiert. Das API- und DB-Schema ist möglicherweise ustable, aber alle Änderungen an diesen werden in den Versionshinweisen angegeben und hook_update_Nimplementiert, um Daten durch Schemaänderungen zu erhalten, jedoch keinen anderen Upgrade- / Aktualisierungspfad. Nicht für Produktionsstätten geeignet. Zielgruppe sind Entwickler, die am Testen, Debuggen und Entwickeln des Projekts teilnehmen möchten.
Beta : Alle kritischen Datenverluste und Sicherheitslücken werden behoben. Wenn das Modul eine API bietet, sollte diese als eingefroren betrachtet werden, damit diejenigen, die die API verwenden, mit dem Upgrade ihrer Projekte beginnen können. Wenn es sich um ein Upgrade oder Update eines Projekts handelt, sollte ein Upgrade- / Update-Pfad angeboten werden, und es sollte vorhandenen Benutzern möglich sein, ohne Datenverlust auf die neue Version zu aktualisieren / zu aktualisieren. Alle Unterlagen sollten auf dem neuesten Stand sein. Zielgruppe sind Entwickler, die am Testen, Debuggen und Entwickeln des Projekts teilnehmen möchten, sowie Entwickler anderer Projekte, die mit dem Projekt verbunden sind. Im Allgemeinen nicht für Produktionsstandorte geeignet, kann jedoch an einigen Produktionsstandorten verwendet werden, wenn der Standortadministrator das Projekt gut kennt und alle verbleibenden Probleme behandelt.
Die Zeichenfolgen "dev" und "stabile" sind nicht als Teil eines Release-Tags gültig, aber nicht getaggte Entwicklungsversionen werden als "dev" angenommen und vom Drupal mit Beschreibungen wie "7.x-1.x-dev" versehen .org Release Packing System, um anzuzeigen, dass es sich um nicht getaggte Entwicklungsversionen handelt.
Alle Release-Tags müssen mit einer Nummer enden. Die Zahlen dienen nur zur Unterscheidung von Releases derselben Klasse. Die erste ist mit "1" (wie in "alpha1"), die nächste mit "2" usw. nummeriert.
PS. Die Zeichenfolgen, die Releases bezeichnen (wie "7.x-1.0-alpha4"), sind im Git-Sprachgebrauch als "Release-Tags" bekannt, nicht als "Namen". Und Sie verwenden niemals die Drupal- Minor- Version als Teil eines Tags, sondern stattdessen "x".