Re: Release process

On Sat, Apr 16, 2022 at 7:17 AM Geoff Westcott <[email protected]> wrote:

> What do you think?

I think that having the ability to "release early
and often" is a good idea, although in some
perfect world we would not have to have so
many fixes (but we all understand screen
scraping is prone to source website changes).

Given that travis-ci is (in some ways)
eliminating the free CI testing that they
previously offered(*), I would think a first
step would be to move to appropriate
github actions for our CI so that any push
(or pull request) results in the workflow
automatically running and generating CI
artifacts for at least a few distros and
generating the windows builds (since
one of the runner types is windows,
presumably it should be possible to create
such steps).

I am willing to (attempt to) create github
actions if the project elders agrees to that
first step (I will likely need help from a
windows expert at some point, as I don't
do windows (although I may be able to
follow the instructions and iterate) but
the instructions about builds include
that failures are expected, which is not
likely to work well with github).  Note that
TTBOMK adding github actions should
not impact the existing travis ci processes,
so I don't think there is any downside for
letting me add the github workflow actions.

For actual grabber testing as part of CI,
some of the grabbers need credentials,
but github has a way to store "secrets"
for such testing (once we get to that point).
It "should" (large quotes around should)
be possible to create an artifact with
the results of testing the grabbers,
although with geofencing the results
may be mostly meaningless, and
feedback from the affected party may
be more useful and attempts at testing.

And there are github actions that can
generate a release either by being
triggered by a version tag push (a push
with a tag of 'v....', typically), or one can
use the github release process.

Quite honestly, the hardest part is likely
the release notes and the email for
the users.

Note that downstream packagers, if
they have proper release monitoring
in place, should get automatically
notified of new releases.  What they
do with such notification varies
(as the rpmfusion packager, I have
added monitoring at release-monitoring.org
for notification to try to update the package
soonish after a release (and occasionally
when I see "significant" patches), but
it (like a lot of this) depends on (my)
available time).

Gary



(*) The entire situation is somewhat
confusing to me as to their new
approach to open source, even as
they indicated that it can, in some
cases, still be free (except when it is
not).