Paketpflege prüft, ob das veröffentlichte Paket eines Projekts aktuell, auflösbar und in seiner Registry nicht als veraltet markiert ist. Registry-Pflege ist etwas anderes als GitHub-Aktivität: Eine Bibliothek kann auf npm oder Packagist veralten — oder ausdrücklich als aufgegeben markiert sein —, während ihr Repository weiterhin Commits erhält; installiert wird aber das Paket, nicht das Repository.
- Kategorie: Nachhaltigkeit & Governance (20% innerhalb der Kategorie)
- Gewicht im Gesamtindex: 4,8%
- Metrikschlüssel:
package_maintenance - Gilt für: Repositories, die mindestens ein Paket veröffentlichen; andernfalls
null
Wie der Wert berechnet wird
| Komponente | Gewicht | Kriterien |
|---|---|---|
| Veröffentlicht & auflösbar | 25 | mindestens eines der Pakete des Repositorys ist in seiner Registry auflösbar |
| Aktualität der Veröffentlichung | 35 | letzte Veröffentlichung ≤180 Tage → 35 Pkt., ≤365 → 26, ≤730 → 14, älter → 4 |
| Versionshistorie | 20 | ≥5 veröffentlichte Versionen → 20, ≥2 → 12, andernfalls 4 |
| Nicht als veraltet markiert | 20 | deprecated (npm), abandoned (Packagist) oder zurückgezogene (yanked) letzte Version → 0; andernfalls 20 |
Warum jede Komponente zählt
- Auflösbarkeit ist die Grundlinie: Das Paket lässt sich aus der Registry installieren, zu der Nutzer tatsächlich greifen würden.
- Aktualität der Veröffentlichung erfasst das stille Versagen, bei dem Korrekturen im Repository landen, aber nie ausgeliefert werden — die Registry-Kopie altert unbemerkt, während das Repository lebendig wirkt.
- Versionshistorie unterscheidet eine gepflegte Release-Linie von einer einmaligen Veröffentlichung.
- Deprecation ist das stärkste Signal der Registry selbst, gesetzt von den Maintainern; eine als veraltet markierte letzte Version setzt die Komponente unmittelbar auf null.
Das Ergebnis lesen
- Im Quervergleich mit der Release-Disziplin lesen: GitHub-Releases und Registry-Veröffentlichungen bewegen sich in der Regel gemeinsam, und ein Auseinanderlaufen ist selbst aufschlussreich.
- Gezählt werden nur Pakete, deren Registry-Metadaten nachweisbar auf das geprüfte Repository verweisen — siehe unterstützte Ökosysteme zur Zuordnungsregel.
- Repositories ohne Veröffentlichungen sind hier
null, und ihre Kategorie wird renormalisiert — niemals eine Strafe dafür, eine Anwendung zu sein.
Den Wert verbessern
- Releases als Teil des Release-Prozesses in die Registry veröffentlichen, nicht als Nachgedanken.
- Für gepflegte Pakete mindestens einen jährlichen Veröffentlichungsrhythmus einhalten — schon ein Patch-Release stellt die Aktualität wieder her.
- Niemals eine als veraltet markierte oder zurückgezogene Version als letzte stehen lassen; einen Nachfolger veröffentlichen oder die Markierung aufheben.
Verwandt: Ökosystem-Verbreitung · Release-Disziplin