Release-Disziplin misst, ob ein Projekt versionierte Releases veröffentlicht — den Mechanismus, über den die Arbeit im Repository die Nutzer tatsächlich erreicht. Nachgelagerte Konsumenten pinnen Versionen, lesen Changelogs und aktualisieren an Release-Grenzen; ein Projekt, das nie Releases schneidet, zwingt jeden Nutzer auf unversionierte Momentaufnahmen.
- Kategorie: Vitalität (40% innerhalb der Kategorie)
- Gewicht im Gesamtindex: 8,8%
- Metrikschlüssel:
release_discipline
Wie der Wert berechnet wird
| Komponente | Gewicht | Kriterien |
|---|---|---|
| Veröffentlicht Releases | 27 | beliebige veröffentlichte Releases; dieselbe Bedingung wie v0.9.0, skaliert auf 27 Punkte |
| Release-Aktualität | 36 | dieselben Schwellwerte wie v0.9.0, skaliert auf 36 Punkte |
| Release-Rhythmus | 27 | dieselben Schwellwerte wie v0.9.0, skaliert auf 27 Punkte |
| OpenSSF Scorecard: Signed-Releases | 10 | Scorecard-Ergebnis 0–10, skaliert auf 10 Punkte |
Sind keine Release-Daten verfügbar, ist die Metrik null — aus Vitalität ausgeschlossen und die Gewichte renormalisiert, niemals als null gewertet. Die Scorecard-Komponente wird ebenso ausgeschlossen, wenn Scorecard nicht verfügbar ist oder n/a meldet; sie bleibt zugleich ein vollwertiges Sicherheitssignal.
Warum Releases getrennt von Commits gemessen werden
Commit-Aktivität und Ausliefern sind verschiedene Disziplinen. Ein Repository kann auf seinem Standardbranch ständige Bewegung zeigen, während Nutzer ein Jahr auf ein Release mit den Korrekturen warten; das Gegenteil — ruhige Branches, pünktliche Releases — existiert ebenfalls. Die Trennung von Entwicklungsaktivität und Release-Disziplin macht beide Muster sichtbar, statt eines das andere verdecken zu lassen.
Das Ergebnis lesen
- Die Aktualität ist die schwerste Komponente. Ein Projekt mit starker Release-Historie, das vor achtzehn Monaten aufgehört hat zu veröffentlichen, liest sich deutlich niedriger als eines, das im letzten Quartal ausgeliefert hat.
- Der Rhythmus belohnt Regelmäßigkeit, nicht Frequenz um ihrer selbst willen. Ein stetiger Quartalszyklus erzielt die meisten Rhythmuspunkte; die oberste Stufe spiegelt lediglich die kurzen Iterationsschleifen wider, die in aktiv entwickelten Bibliotheken üblich sind.
- GitHub-Releases sind die Quelle. Projekte, die Versionen nur taggen, ohne Releases zu veröffentlichen, oder ausschließlich über eine Registry veröffentlichen, können sich hier niedriger lesen; die Aktualität der Registry-Veröffentlichungen wird separat in der Paketpflege gemessen.
Den Wert verbessern
- Releases über den Release-Mechanismus des Repositorys veröffentlichen, nicht nur als Tags.
- In einem vorhersehbaren Rhythmus veröffentlichen — kleine, regelmäßige Releases erzielen höhere Werte als seltene große und dienen den Nutzern aus demselben Grund besser.
- Nach jeder Ruhephase stellt ein einzelnes frisches Release die Aktualitätskomponente sofort wieder her.
Verwandt: Entwicklungsaktivität · Paketpflege