Re: Release process

On Mon, Apr 18, 2022 at 11:42 PM Robert Eden <[email protected]> wrote:

> I see no reason not to give it a shot.  I've offered before to automate
> the building of XMLTV on my system.  I'll look into it next time I see a
> commit.

Without any objection, I'll commit the github workflow
that should build on pushes and creates an xmltv.exe
artifact.  That is the first step.  If someone decides that
this is a bad idea, removing the workflow is just another
commit and push.

> Whoever commits the "magic V*" comment would have the responsibility to
> update the README and other files first.  Heck, maybe your script can
> make sure that's updated before processing the V* message. (or better
> yet, make sure the V* log and README match.

As I recall, rejecting a push due to failing tests requires
(client side) hooks, but first let's just try building on pushes
before expanding to (semi) automating releases.  Simply
ignoring a v* tag can be done centrally, but might result
in some confusion IRT official releases.  Likely something
additional to consider.

> For notifications, we could even go full github and have it send the
> announcements or script it.  Once the readme is done, the rest is pretty
> easy.

In order to prevent github from becoming (yet another)
spam source, sending email directly from github actions
is complicated (one needs to have a (stored) secret
that is typically given to an email provider so that
there is a clear validated/authenticated pipeline that
can be revoked if abused).  If one uses a self-hosted
runner one can sometimes bypass some of the checks.