GitHub-Releases in einem RSS-Reader verfolgen

Jedes Repository hat einen Release-Feed

GitHub veröffentlicht für jedes öffentliche Repository einen Feed der Releases. Hängen Sie /releases.atom an das Ende der Repository-Adresse an:

https://github.com/OWNER/REPO/releases.atom

Für die GitHub CLI, deren Repository cli/cli ist, lautet das:

https://github.com/cli/cli/releases.atom

Der Feed liegt im Atom-Format vor, das RSS-Reader genauso verarbeiten wie RSS. Jeder Eintrag entspricht einem Release, mit dem Release-Titel, einem Link zur Release-Seite, dem Veröffentlichungszeitpunkt und den Release-Notizen, wie sie die Maintainer auf GitHub geschrieben haben. Der Feed enthält die 10 neuesten Releases. Sie benötigen weder ein GitHub-Konto noch einen Token oder einen Drittanbieterdienst, um ihn zu verwenden.

Einen Release-Feed zu SereneReader hinzufügen

1. Öffnen Sie das Repository auf GitHub und kopieren Sie den OWNER/REPO-Teil der Adresse, zum Beispiel cli/cli.
2. Erstellen Sie die Feed-URL: https://github.com/cli/cli/releases.atom.
3. Klicken Sie in SereneReader auf Feed hinzufügen am unteren Rand der Seitenleiste und fügen Sie die URL in das Feld Feed-URL ein.
4. Tragen Sie einen Eigenen Titel ein. GitHub benennt den Feed nur nach dem Repository, daher erscheint der GitHub-CLI-Feed als „Release notes from cli". Ein Titel wie „GitHub CLI releases" lässt sich in der Seitenleiste leichter finden.
5. Wählen Sie einen Ordner, falls Sie einen für Releases angelegt haben, und klicken Sie dann auf Feed hinzufügen.

Neue Releases erscheinen dann zusammen mit Ihren anderen Artikeln, und die Release-Notizen öffnen sich im Reader wie jeder andere Beitrag.

Release-Feeds in einem Ordner zusammenfassen

Wenn Sie mehr als einige wenige Projekte verfolgen, legen Sie einen Ordner dafür an. Klicken Sie in der Seitenleiste auf Neuer Ordner, geben Sie ihm einen Namen wie „Releases" und wählen Sie ihn beim Hinzufügen jedes Feeds aus. Öffnen Sie den Ordner, wenn Sie sehen möchten, was sich in den von Ihnen verwendeten Tools geändert hat, und lassen Sie ihn den Rest der Zeit geschlossen.

Weitere Feeds, die GitHub veröffentlicht

Das gleiche Muster funktioniert für einige weitere Seiten. Wir haben diese alle am 3. November 2026 anhand echter Repositories überprüft.

Einige Beispiele zum Kopieren:

https://github.com/cli/cli/tags.atom
https://github.com/cli/cli/commits/trunk.atom
https://github.com/cli/cli/commits.atom
https://github.com/cli/cli/discussions.atom
https://github.com/vitejs/vite/commits/main/packages/vite/CHANGELOG.md.atom
https://github.com/torvalds.atom

Ein paar hilfreiche Details:

• /commits.atom ohne Branch folgt dem Standard-Branch des Repositories. Bei cli/cli liefert das dieselben Einträge wie /commits/trunk.atom.
• Ein nicht vorhandener Branch gibt einen 404-Fehler zurück. Überprüfen Sie den Branch-Namen, wenn ein Reader meldet, dass er den Feed nicht finden kann.
• Der Datei-Feed ist nützlich für Changelogs. Manche Projekte schreiben ihre Notizen in eine CHANGELOG.md-Datei statt in GitHub-Releases. Commits zu dieser Datei zu verfolgen zeigt an, wenn sich der Changelog ändert – wie im obigen Vite-Beispiel.
• Projekte, die Versionen taggen, ohne GitHub-Releases zu veröffentlichen, haben dennoch einen funktionierenden Release-Feed. Linux und Go veröffentlichen keine GitHub-Releases, und ihre releases.atom-Feeds listen stattdessen ihre Tags auf. Der Eintragstext ist die Commit-Nachricht, also kurz.

Was ist mit einer ganzen Organisation?

GitHub veröffentlicht keinen übergreifenden Release-Feed für eine Organisation. https://github.com/ORG.atom gibt einen gültigen Feed zurück, der jedoch Organisationsereignisse enthält, etwa das Hinzufügen von Personen zu Repositories. Bei den Organisationen cli und github war er leer. https://github.com/orgs/ORG.atom gibt eine Webseite zurück, keinen Feed.

Um jedes Repository einer Organisation zu verfolgen, abonnieren Sie den Release-Feed jedes einzelnen Repositories. Das müssen Sie nicht manuell tun: Das folgende Skript fragt die API von GitHub nach den öffentlichen Repositories der Organisation und schreibt eine OPML-Datei – das Format, das Reader zum Importieren einer Feed-Liste verwenden. Es benötigt curl und jq, liest bis zu 100 Repositories und überspringt archivierte.

ORG=cli

curl -s "https://api.github.com/orgs/$ORG/repos?per_page=100&type=public" \
  | jq -r --arg org "$ORG" '
      "<?xml version=\"1.0\" encoding=\"UTF-8\"?>",
      "<opml version=\"2.0\">",
      "  <head><title>\($org) releases</title></head>",
      "  <body>",
      "    <outline text=\"\($org) releases\">",
      (.[] | select(.archived | not) | "      <outline type=\"rss\" text=\"\(.full_name)\" xmlUrl=\"https://github.com/\(.full_name)/releases.atom\"/>"),
      "    </outline>",
      "  </body>",
      "</opml>"' > "$ORG-releases.opml"

Ersetzen Sie ORG durch die gewünschte Organisation, führen Sie das Skript aus und importieren Sie die Datei: Klicken Sie in SereneReader auf Feed hinzufügen, dann auf OPML importieren. Die Feeds landen in einem Ordner – in diesem Beispiel mit dem Namen „cli releases". Große Organisationen können Hunderte von Repositories haben, prüfen Sie die Datei daher vor dem Import. Im Free-Plan stoppt ein Import beim Limit von 150 Feeds.

Lassen sich Vorab-Versionen herausfiltern?

Nicht im Feed selbst. Der Release-Feed enthält Vorab-Versionen (Pre-releases), und kein Eintragsfeld kennzeichnet sie als solche. Wir haben das anhand von TypeScript überprüft: GitHub markiert „TypeScript 7.1 Beta" als Pre-release, aber der Feed-Eintrag sieht genauso aus wie der eines stabilen Releases. Das Anhängen von ?prerelease=false an die Feed-URL ändert nichts an dem, was GitHub zurückgibt.

Filtern lässt sich hingegen nach dem Release-Titel. Viele Projekte fügen „beta", „rc" oder „alpha" in die Namen ihrer Vorab-Versionen ein. Fügen Sie in SereneReader unter Einstellungen > Daten > Versteckte Phrasen einen Begriff hinzu, oder öffnen Sie einen Release, klicken Sie auf Artikel ausblenden und wählen Sie Nach Phrase ausblenden. Artikel, deren Titel oder Zusammenfassung die Phrase enthält, werden ausgeblendet – auch solche, die später eintreffen. Die Phrase -rc blendet beispielsweise Linux-Release-Kandidaten wie v7.4-rc1 aus.

Wählen Sie die Phrase sorgfältig. Versteckte Phrasen gelten für jeden Feed, dem Sie folgen, und sie treffen sowohl den Titel als auch die Zusammenfassung. Eine Phrase wie beta blendet auch ein stabiles Release aus, dessen Notizen eine Beta erwähnen, sowie Beiträge in Ihren anderen Feeds, die das Wort verwenden.

Noch etwas zu beachten: Ein Repository, das mehrere Pakete enthält, veröffentlicht deren Releases häufig im selben Feed. Der TypeScript-Feed listet auch Releases der dazugehörigen VS Code-Erweiterung auf, mit Titeln wie vscode-typescript/v1.0.1. Eine versteckte Phrase wie vscode-typescript/ entfernt diese.

Releases mit einem KI-Agenten lesen

Wenn Sie viele Projekte verfolgen, möchten Sie möglicherweise eine Zusammenfassung statt jedes einzelnen Satzes von Notizen. Die API von SereneReader gibt Ihre Artikel als JSON zurück – einschließlich der aus Release-Feeds –, sodass ein Agent oder ein kurzes Skript die Releases der vergangenen Woche lesen und Ihnen mitteilen kann, welche für Sie relevant sind. So verbinden Sie Ihre RSS-Feeds mit KI-Agenten führt Sie durch die Einrichtung. Die API ist Bestandteil der Pro- und Team-Pläne.

Wenn ein Feed nicht ausreicht

Ein Release-Feed ist eine ruhige Möglichkeit, die von Ihnen verwendete Software im Blick zu behalten. Er hat jedoch Grenzen:

• Die Notizen sind nur so gut wie der Release selbst. Der Feed enthält den Release-Text und nichts weiter. Linux-Release-Einträge enthalten nur eine Zeile wie „Linux 7.4-rc1", und der TypeScript-Beta-Eintrag ist ein Link zu einem Blogbeitrag. Die an einen Release angehängten Dateien werden ebenfalls nicht aufgelistet. Für solche Projekte empfiehlt es sich, zusätzlich den Blog-Feed des Projekts oder seine Changelog-Datei zu verfolgen.
• Private Repositories funktionieren nicht. Der Feed eines privaten Repositories gibt einen 404-Fehler zurück, sofern Sie nicht bei GitHub angemeldet sind – und ein RSS-Reader ruft Feeds ohne Ihre GitHub-Sitzung ab. Nutzen Sie für diese Repositories die eigenen Benachrichtigungen von GitHub (siehe unten).
• Neue Releases erscheinen nach dem Zeitplan des Readers. Ein Reader prüft jeden Feed in regelmäßigen Abständen, daher erscheint ein Release beim nächsten Abruf, nicht im Moment der Veröffentlichung. Zum Lesen ist das in Ordnung. Es ist nicht das richtige Werkzeug, wenn etwas sofort geschehen muss.
• Aktive Feeds können Einträge verpassen. Der Feed enthält immer nur die 10 neuesten Releases. Ein Repository, das zwischen zwei Abrufen mehr als 10 Releases veröffentlicht – etwa ein großes Monorepo am Release-Tag –, lässt einige davon verschwinden, bevor ein Reader sie sieht.

Wenn diese Grenzen ins Gewicht fallen, verwenden Sie stattdessen eine der folgenden Möglichkeiten:

• Das Watch-Menü von GitHub. Klicken Sie auf der Repository-Seite auf Watch, wählen Sie Custom und aktivieren Sie Releases. GitHub sendet dann für jeden neuen Release eine Benachrichtigung und, sofern aktiviert, auch eine E-Mail. Das funktioniert auch für private Repositories, auf die Sie Zugriff haben.
• Ein Webhook. Wenn ein Release etwas automatisch auslösen soll – etwa einen Build oder ein Deploy –, ruft ein Repository-Webhook mit dem Release-Ereignis Ihren Server auf, wenn der Release veröffentlicht wird. Webhooks können nur zu Repositories hinzugefügt werden, die Sie verwalten.
• Tools zur Abhängigkeitsaktualisierung. Wenn das Ziel darin besteht, die Abhängigkeiten eines Projekts aktuell zu halten, öffnet ein Tool wie Dependabot oder Renovate Pull Requests, wenn neue Versionen erscheinen.

Um mit den Tools, auf die Sie angewiesen sind, auf dem Laufenden zu bleiben, ohne ein weiteres Postfach verwalten zu müssen, ist der Feed in der Regel ausreichend.

Feed-URLs und ihre Inhalte wurden am 3. November 2026 anhand von GitHub überprüft. Wenn ein Feed aufhört, sich zu aktualisieren, öffnen Sie seine URL im Browser, um zu prüfen, ob GitHub ihn noch ausliefert.