On 12/7/22 19:07, Peter Hutterer wrote:
fwiw, I've done similar things in the past, pushing a release out just
to make some internal processes easier. It's simpler to update to a new
version than shipping the one patch that's actually needed (and all
other patches are just readme changes and whatnot).

But for me, the threshold is the tarball, not the installed files.
The only time I wouldn't create a release is when the tarball is
effectively identical. Which is basically anything that's CI-only.
But anything that affects the delivered tarball can be subjected to a
release.

Fair enough.

This goes doubly now that many repos have changed to xz so we have a mix
of tarball types too. Releasing everything in one group to get some
consistency is useful.

That almost sounds katamari-like. Fortunately, we're getting most things
released without the overhead of a katamari release anyway.

And as the font bugs show, sometimes a release is warranted just to
update the tarball with more modern generated files.

Yeah - I know they can just run autogen.sh or autoreconf to get their
builds to work, but I know it's less work to just have upstream usable
right out of the tarball.  (And of course, once everything builds with
meson and the autoconf infrastructure is removed, that goes away, but
we don't have enough people converting modules to meson to see that yet.)

IOW, let's not worry about whether releases happen too often, it's a lot
easier for distributions to ignore a released tarball than it is to wish
a newer one into existence :) Especially since "too often" here still
means years in between the releases anyway.

Okay - I guess I just see things like
https://repology.org/project/fonts:adobe-100dpi/versions
or
https://repology.org/project/libx11/versions
and think about how many different packagers I'm making do work, but
if that work is just changing the version number of the tarball they
download, they should have that pretty well automated by now.

--
        -Alan Coopersmith-                 alan.coopersm...@oracle.com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Reply via email to