Wie kommen Module zu ihren grünen, gelben und roten Releases?

Wie wir alle wissen, ist nicht jedes Modul mit der Aufschrift "Recommended Release" auf drupal.org wirklich stabil. Tatsächlich sind einige Module ständig als Beta gekennzeichnet, in einer Art permanentem Schwebezustand. Selbst wenn Hunderte von Websites sie jeden Tag verwenden.

Ich habe mich gefragt, welche Art von Standards oder Best Practices Sie als Betreuer oder Mitwirkender in Ihren Modulen verwenden, um die Releases "Empfohlen" (Grün), "Andere" (Gelb) oder "Entwickler" (Rot) zu markieren. Was verwenden Sie, wenn Sie es als Beta, Alpha oder Stable markieren?

Vielen Dank im Voraus für Ratschläge, Hilfe oder Dokumentation, die Sie bereitstellen können.

HINWEIS: Viele dieser Standards können allgemeine Standards für die Codierung oder Projektentwicklung sein. Ich wollte einfach nur wissen, welche Methoden oder Standards in Drupal-Modulen speziell verwendet werden, auch wenn sie verallgemeinert sind / werden können.

Viele dieser Standards können allgemeine Standards für die Codierung oder Projektentwicklung sein.

In Drupal gibt es dafür keinen Standard. Es bleibt den besten Absichten der Modulbesitzer überlassen.

Meine persönliche Philosophie ist:

• Geben Sie Beta und / oder Release Candidate frei, wenn Sie in einer Testumgebung getestet wurden oder wenn alle Testfälle bestanden wurden.
• Release Stable nur, wenn ich selbst das (Version des) Moduls erfolgreich in mindestens drei verschiedenen realen Projekten implementiert habe. oder wenn jemand, den ich kenne, meine Standards hat, hat das getan und berichtet zurück.
• Ein Modul kann sein abgeschlossen . Es braucht nie mehr zusätzliche Arbeit. Etwas, das in Featuresets begrenzt und begrenzt ist, ist stabil und vorhersehbar. Solche Module benötigen keine Bugfixes, Feature-Requests oder Tasks.

In der Praxis bedeutet dies nur sehr wenige Veröffentlichungen, die vorgenommenen Veröffentlichungen werden jedoch kaum jemanden betreffen. Das führt dazu, dass in der Praxis kaum etwas veröffentlicht wird.

Meine Argumentation dahinter ist:

• Leute in Problemwarteschlangen testen kaum angemessen: Sie wenden eine Funktion an, korrigieren oder patchen, drücken f5, sehen, wie es funktioniert und sagen "Ja, funktioniert für mich +1". "Es scheint zu funktionieren" ist nicht gleich "es ist behoben" . Sie brauchen vertrauenswürdige Tests, oder der Rest, diejenigen, die die Änderung nicht einmal getestet haben, werden sich mit Problemen beschäftigen, die etwas VOLLSTÄNDIGES BORKEND melden, das JETZT behoben werden muss !!.
• Nur wenn ein Modul in verschiedenen Situationen und Umgebungen implementiert ist, verfügt es über praktische Erfahrungen. In den meisten Fällen müssen Sie während der zweiten Implementierung einige zentrale APIs neu schreiben, einige nützliche Parameter vergessen oder hatten einfach eine falsche Vorstellung von der Notwendigkeit einer Funktion. Erst nach einer realen Bereitstellung kann etwas als stabil angesehen werden. Sonst ist es nur theoretisch stabil.
• Entwickler und Betreuer von Websites, die Benutzer Ihrer Module, müssen große Anstrengungen unternehmen (weitaus mehr als bei jeder anderen mir bekannten Software), um mit neuen Versionen, Sicherheitsversionen und neuen Versionen Schritt zu halten. Jede Erleichterung für diese Bemühungen (und Budget und Zeit) sollte mehr als willkommen sein.

Wenn Sie ein Modul verwenden, in dem Sie Fehler gefunden haben, können Sie am besten ein Problem melden. Noch besser ist es, wenn jemand einen Patch für dieses Problem schreibt. Der Patch kann von einem Entwickler geschrieben werden, der die Funktion benötigt, oder von einem Entwickler, der für das Schreiben dieses Patches gesponsert wurde. Contrib-Betreuer warten normalerweise viele Module, und wenn Sie ein Modul erstellen, werden Sie automatisch zum Betreuer. Dies belastet uns natürlich sehr. Daher benötigen wir immer Hilfe von Personen, die Patches schreiben, Patches sponsern oder überprüfen.

Wenn Sie Releases in drupal.org pflegen, haben Sie ein Kontrollkästchen "Unterstützt", mit dem Sie eine empfohlene Version erhalten (grün). Wenn Sie auch die Option "Snapshot-Version anzeigen" aktivieren, erhalten Sie eine Entwicklungsversion (rot). Wenn Sie mehr als eine Hauptversion Ihres Moduls (6.1 und 6.2) haben, können Sie im empfohlenen Release-Bereich (grün) auswählen, welche Version verfügbar sein soll. Nur Betas und reguläre Releases werden in den Abschnitt "Empfohlen" (grün) aufgenommen, und niedrigere Releases werden im Abschnitt "Andere Releases" (gelb) angezeigt.

In Bezug auf Betas, Rcs und Dev hängt es von der Popularität und Nische ab, die Ihr Modul imo füllt.

Wenn Earl eine offizielle Version von Ansichten herausbringt, bei denen ein Datenverlust auftritt, funktioniert das Internet möglicherweise nicht mehr.

Wenn Sie jedoch ein kleines Modul haben, das relativ unbeliebt ist (> 1.000 Benutzer) und nur routinemäßige Bugfixes durchlaufen, ist es sinnvoller, nur neue Releases zu erstellen und diese nicht zu testen.

Wenn Sie wissen, dass Sie einige große Änderungen vorgenommen oder eine Menge Abwanderung gesehen haben, testen Sie diese gründlicher.

Ich neige dazu, betas / rc zu testen und zu rollen, wenn ich die Datenbank ändere oder update () - Hooks ausstelle, weil ich die Dauerhaftigkeit des Datenverlusts erkenne. Ich kann eine kleine Fehlerbehebung weltweit schnell wiederholen und erneut veröffentlichen, aber ich kann Ihre Site-Daten neu erstellen.

Ich hoffe, das hilft.