GitHub-releases volgen in een RSS-lezer
Elk repository heeft een release-feed
GitHub publiceert een feed van releases voor elk openbaar repository. Voeg /releases.atom toe aan het einde van het adres van het repository:
https://github.com/OWNER/REPO/releases.atomVoor de GitHub CLI, waarvan het repository cli/cli is, wordt dat:
https://github.com/cli/cli/releases.atomDe feed is in Atom, een feedformaat dat RSS-lezers op dezelfde manier verwerken als RSS. Elke vermelding is één release, met de titel van de release, een link naar de releasepagina, de publicatietijd en de release-opmerkingen zoals de beheerders die op GitHub hebben geschreven. De feed bevat de 10 meest recente releases. Je hebt geen GitHub-account, token of dienst van derden nodig om hem te gebruiken.
Een release-feed toevoegen aan SereneReader
- Open het repository op GitHub en kopieer het gedeelte
OWNER/REPOvan het adres, bijvoorbeeldcli/cli. - Bouw de feed-URL:
https://github.com/cli/cli/releases.atom. - Klik in SereneReader op Feed toevoegen onderaan de zijbalk en plak de URL in Feed-URL.
- Vul Aangepaste titel in. GitHub geeft de feed alleen de naam van het repository, dus de GitHub CLI-feed verschijnt als "Release notes from cli". Een titel zoals "GitHub CLI releases" is gemakkelijker te vinden in de zijbalk.
- Kies een Map als je er een hebt voor releases, en klik vervolgens op Feed toevoegen.
Nieuwe releases verschijnen dan samen met je andere artikelen, en de release-opmerkingen openen in de lezer zoals elk ander bericht.
Release-feeds in één map bewaren
Als je meer dan een paar projecten volgt, maak dan een map voor ze. Klik op Nieuwe map in de zijbalk, geef hem een naam zoals "Releases" en kies hem wanneer je elke feed toevoegt. Open de map wanneer je wilt zien wat er veranderd is in de tools die je gebruikt, en laat hem de rest van de tijd gesloten.
Andere feeds die GitHub publiceert
Hetzelfde patroon werkt voor enkele andere pagina's. We hebben elk van deze gecontroleerd aan de hand van echte repositories op 3 november 2026.
| Wat je wilt volgen | Feed-URL | Wat elke vermelding bevat |
|---|---|---|
| Releases | https://github.com/OWNER/REPO/releases.atom |
Releasetitel en volledige release-opmerkingen (10 meest recente) |
| Tags | https://github.com/OWNER/REPO/tags.atom |
Tag- of releasetitel, met het bericht van de getagde commit in plaats van de release-opmerkingen (10 meest recente) |
| Commits op een branch | https://github.com/OWNER/REPO/commits/BRANCH.atom |
Commitbericht (20 meest recente) |
| Commits naar één bestand of map | https://github.com/OWNER/REPO/commits/BRANCH/PATH.atom |
Commitbericht voor commits die dat pad hebben geraakt (20 meest recente) |
| Discussies | https://github.com/OWNER/REPO/discussions.atom |
Nieuwe discussies, voor repositories waarbij Discussions is ingeschakeld |
| Openbare activiteit van een gebruiker | https://github.com/USER.atom |
Pushes, verwijderde branches en andere openbare gebeurtenissen (30 meest recente) |
Enkele kopieer-plak-voorbeelden:
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.atomEen paar details die helpen:
/commits.atomzonder branch volgt de standaardbranch van het repository. Voorcli/cligeeft het dezelfde vermeldingen terug als/commits/trunk.atom.- Een branch die niet bestaat geeft een 404-fout, dus controleer de branchnaam als een lezer aangeeft dat de feed niet gevonden kan worden.
- De bestandsfeed is handig voor changelogs. Sommige projecten schrijven hun opmerkingen in een
CHANGELOG.md-bestand in plaats van in GitHub-releases. Het volgen van commits naar dat bestand vertelt je wanneer de changelog verandert, zoals in het Vite-voorbeeld hierboven. - Projecten die versies taggen zonder GitHub-releases te publiceren hebben nog steeds een werkende release-feed. Linux en Go publiceren geen GitHub-releases, en hun
releases.atom-feeds vermelden hun tags. De tekst van de vermelding is het commitbericht, dus die is kort.
Wat als je een hele organisatie wilt volgen?
GitHub publiceert geen feed van releases voor een hele organisatie. https://github.com/ORG.atom geeft een geldige feed terug, maar die bevat organisatiegebeurtenissen zoals mensen die aan repositories worden toegevoegd. Voor de cli- en github-organisaties was hij leeg. https://github.com/orgs/ORG.atom geeft een webpagina terug, geen feed.
Om elk repository in een organisatie te volgen, abonneer je je op de release-feed van elk repository afzonderlijk. Dat hoef je niet met de hand te doen: het script hieronder vraagt de API van GitHub naar de openbare repositories van de organisatie en schrijft een OPML-bestand, het formaat dat lezers gebruiken om een lijst van feeds te importeren. Het heeft curl en jq nodig, leest maximaal 100 repositories en slaat gearchiveerde repositories over.
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"Verander ORG in de organisatie die je wilt, voer het script uit en importeer het bestand: klik in SereneReader op Feed toevoegen en vervolgens op OPML importeren. De feeds komen in één map terecht, in dit voorbeeld met de naam "cli releases". Grote organisaties kunnen honderden repositories hebben, dus controleer het bestand voordat je het importeert. Bij het gratis abonnement stopt een import bij de limiet van 150 feeds.
Kun je pre-releases overslaan?
Niet in de feed zelf. De release-feed bevat pre-releases, en niets in een vermelding markeert hem als zodanig. We hebben dit gecontroleerd met TypeScript: GitHub markeert "TypeScript 7.1 Beta" als een pre-release, maar de feedvermelding ziet er hetzelfde uit als die van een stabiele release. Het toevoegen van ?prerelease=false aan de feed-URL verandert niets aan wat GitHub teruggeeft.
Wat je wel kunt filteren, is de releasetitel. Veel projecten vermelden "beta", "rc" of "alpha" in de namen van pre-releases. Voeg in SereneReader een zin toe via Instellingen > Gegevens > Verborgen zinnen, of open een release, klik op Artikel verbergen en kies Verbergen op zin. Artikelen waarvan de titel of samenvatting de zin bevat, worden verborgen, inclusief artikelen die later binnenkomen. De zin -rc verbergt bijvoorbeeld Linux-releasekandidaten zoals v7.4-rc1.
Kies de zin zorgvuldig. Verborgen zinnen gelden voor elke feed die je volgt, en ze komen overeen met zowel de samenvatting als de titel. Een zin zoals beta verbergt ook een stabiele release waarvan de opmerkingen een beta noemen, en berichten in je andere feeds die het woord gebruiken.
Nog iets om op te letten: een repository met meerdere pakketten publiceert vaak releases voor al die pakketten in dezelfde feed. De TypeScript-feed vermeldt ook releases van de VS Code-extensie, met de titel vscode-typescript/v1.0.1. Een verborgen zin zoals vscode-typescript/ verwijdert die.
Releases lezen met een AI-agent
Als je veel projecten volgt, wil je misschien een samenvatting in plaats van elke set opmerkingen. De API van SereneReader geeft je artikelen terug als JSON, inclusief die uit release-feeds, zodat een agent of een kort script de releases van de afgelopen week kan lezen en je kan vertellen welke voor jou relevant zijn. Hoe je RSS-feeds verbindt met AI-agenten doorloopt de installatie. De API maakt deel uit van de Pro- en Team-abonnementen.
Wanneer een feed niet genoeg is
Een release-feed is een rustige manier om bij te blijven met de software die je gebruikt. Hij heeft zijn beperkingen:
- De opmerkingen zijn alleen zo goed als de release zelf. De feed bevat alleen de releasetekst. Linux-releasevermeldingen bevatten slechts één regel zoals "Linux 7.4-rc1", en de TypeScript-beta-vermelding is een link naar een blogbericht. De bestanden die bij een release zijn bijgevoegd, worden ook niet vermeld. Voor zulke projecten kun je ook de blogfeed of het changelogbestand van het project volgen.
- Privérepositories werken niet. De feed van een privérepository geeft een 404-fout tenzij je bent ingelogd bij GitHub, en een RSS-lezer haalt feeds op zonder je GitHub-sessie. Gebruik voor die gevallen de eigen meldingen van GitHub (zie hieronder).
- Nieuwe releases verschijnen op het schema van de lezer. Een lezer controleert elke feed periodiek, dus een release verschijnt bij de volgende controle, niet op het moment dat hij wordt gepubliceerd. Dat is prima voor lezen. Het is niet het juiste middel als er onmiddellijk iets moet gebeuren.
- Drukke feeds kunnen vermeldingen missen. De feed bevat altijd slechts de 10 meest recente releases. Een repository dat meer dan 10 releases publiceert tussen twee controles, zoals een groot monorepo op de dag van een release, duwt sommige vermeldingen eruit voordat een lezer ze ziet.
Als die beperkingen een rol spelen, gebruik dan een van de volgende alternatieven:
- Het Watch-menu van GitHub. Klik op de repositorypagina op Watch, kies Custom en selecteer Releases. GitHub stuurt dan een melding, en een e-mail als je e-mail hebt ingeschakeld, voor elke nieuwe release. Dit werkt ook voor privérepositories waartoe je toegang hebt.
- Een webhook. Als een release automatisch iets moet starten, zoals een build of een deploy, roept een repository-webhook met het release-event je server aan wanneer de release wordt gepubliceerd. Je kunt alleen webhooks toevoegen aan repositories die je beheert.
- Tools voor het bijwerken van afhankelijkheden. Als het doel is om de afhankelijkheden van een project actueel te houden, opent een tool zoals Dependabot of Renovate pull requests wanneer nieuwe versies uitkomen.
Voor het bijhouden van de tools waarvan je afhankelijk bent, zonder nog een inbox te beheren, is de feed doorgaans voldoende.
Feed-URL's en hun inhoud zijn gecontroleerd aan de hand van GitHub op 3 november 2026. Als een feed stopt met bijwerken, open dan de URL in een browser om te controleren of GitHub hem nog steeds aanbiedt.