Checkliste für die Bundle-Veröffentlichung #

Diese Seite richtet sich an die Person, die bei einem Bundle auf "Veröffentlichen" drückt. Arbeiten Sie sie für jedes Release ab; ein veröffentlichtes Release lässt sich nicht zurücknehmen, nur durch das nächste ablösen.

Inhalt #

1. Bevor Sie beginnen
2. Inhalt des Bundles
3. Lizenzen und Hinweise
4. Sicherheit
5. Tests
6. Dokumentation
7. Veröffentlichen

Bevor Sie beginnen #

• To do: Die nächste Versionsnummer ist nach dem gewählt, was bereits veröffentlicht ist (Ihre Tags und Releases, mit Versionssortierung aufgelistet: git tag -l 'v*' --sort=version:refname), nicht aus dem Gedächtnis.
• To do: Die Exponential-Version ist aus den veröffentlichten Tags gewählt, ebenfalls mit Versionssortierung (Versionen, Tags und Pinning).
• To do: Die Release-Hinweise jedes Exponential-Releases seit Ihrem letzten Bundle sind gelesen, einschließlich der Upgrade-Hinweise.

Inhalt des Bundles #

• To do: Kernel auf einen Tag (oder einen festgehaltenen Commit) festgelegt; composer.lock eingecheckt; gebaut mit composer install --no-dev.
• To do: Erweiterungen bewusst hinzugefügt oder entfernt und festgehalten (Erweiterungen hinzufügen und entfernen).
• To do: Die .ezpkg-Dateien der Seitenpakete sind die getesteten, mit Prüfsummen (Seitenpakete in einem Bundle).
• To do: Laufzeitumgebung festgelegt: Digest des Basis-Images, PHP-Version, Velocity-Version.
• To do: Autoloads neu erzeugt; keine Build-Caches ausgeliefert (Caches und Autoloads).
• To do: Ihre Version steht in dem Commit, den Sie taggen, in Ihren Dateien.

Lizenzen und Hinweise #

• To do: LICENSE, LICENSE.md, COPYRIGHT.md aus der ausgelieferten Version enthalten (Lizenztexte und Hinweise).
• To do: Liste der Komponenten Dritter erzeugt und geprüft (Komponenten Dritter).
• To do: Ihre eigenen Teile haben übereinstimmende Lizenzfelder (Lizenzfelder).
• To do: Der zugehörige Quellcode ist veröffentlicht oder angeboten, und die Release-Hinweise sagen, wo (GPL-Pflichten).
• To do: Die Dokumentation behält ihre GFDL-Hinweise (Mitzuliefernde Dokumentation).

Sicherheit #

• To do: Kein settings/override/, settings/siteaccess/, keine kickstart.ini, Protokolle oder initial-admin-password aus dem Build.
• To do: Kein festes Administratorpasswort; Übergabe dokumentiert (Standardzugangsdaten).
• To do: Kein EXP_DEMO_MODE außerhalb von Demo-Bundles (Demo-Modus in Bundles).
• To do: Gehärtete Dateimodi und Besitzrechte (Dateirechte).
• To do: Die Go-live-Punkte, die ein Bundle klären kann, sind geklärt (Sicherheitsvorgaben).

Tests #

• To do: Testmatrix ausgeführt und protokolliert (Ein Bundle testen).
• To do: Upgrade vom vorigen Bundle-Release getestet.
• To do: Ergebnis von php bin/php/checkmanifest.php --all festgehalten (Integritätsprüfungen).
• To do: Arbeitsbaum sauber; das Artefakt entspricht den getaggten Quellen.

Dokumentation #

• To do: Erste Schritte, Adressen, Passwortübergabe.
• To do: Was enthalten ist, mit Versionen.
• To do: Wie aktualisiert wird und welche Datenbankschritte nötig sind (Updates und Upgrade-Pfade).
• To do: Grenzen des Supports (Grenzen des Supports).
• To do: Änderungsprotokoll mit Added, Updated, Removed, Renamed.

Veröffentlichen #

• To do: Name und Beschreibung folgen den Markenregeln (Benennen und Gestalten).
• To do: Prüfsummen (SHA256SUMS) mit den Artefakten veröffentlicht.
• To do: Der Tag wird erst gepusht, nachdem jede Prüfung oben bestanden ist. Verschieben, löschen oder erstellen Sie ihn danach nie neu; ein Fehler wird mit dem nächsten Release behoben, mit einem Hinweis, was falsch war.
• To do: Das Release wird Ihren Empfängern angekündigt und, wenn Sie Partner sind, beim Partnerteam erfasst (Ihre Partneraktivität erfassen).

Verwandte Seiten #

• Arbeitsblatt für Bundles
• Ein Bundle testen
• Versionen, Tags und Pinning
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.