From: Fabian Stelzer Date: Sun, 05 Dec 2021 10:54:41 GMT Subject: Re: [PATCH] githubci: add a workflow for creating GitHub release notes Message-ID: <20211205105441.vsgyef3njcggbzku@fs> In-Reply-To: On 04.12.2021 17:25, Junio C Hamano wrote: >Fabian Stelzer writes: > >> One benefit that I see is that github offers APIs & Notifications >> around releases and lots of CI integration already exist for it. If my >> (non github) CI includes building the git source then i can easily >> trigger when upstream releases a new version. Just pulling the repo >> and watching for the tag works just as well of course. > >Ahh, thanks. > >If some sort of "push" notification is available only for "there is >a new release" but not for "there is a new tag", then I can sort of >see why having a "release" would be nice. Listening to notifications >and acting on them is more pleasant than having to poll. > >Do I understand what you said correctly? > Yes, thats correct. Github has a webhook for releases: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#release Getting tags means listening to every push and filtering yourself: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#push Still, if this gets added to git/git I think the risk of users considering the github release to be the primary source is quite high since lots of tools and CI integrations use them. I'm not a fan of depending on github for everything, but as long as the kernel.org releases don't go away I don't think this is a big deal.