On 04.12.2021 17:25, Junio C Hamano wrote:
Fabian Stelzer <fs@xxxxxxxxxxxx> 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.