Re: Distfiles

[Jim Meyering]

On Wed, Sep 9, 2020 at 8:50 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 9/8/20 10:04 AM, Issam E. Maghni wrote:
>
> > Could you please offer .tar.gz ditfiles on upcoming releases? It’s already 
> > the
> > case for GNU Coreutils, starting from version 8.32, and GNU sed, starting 
> > from
> > version 4.8 thanks to the push from Guix team [1].
> >
> > [1] 
> > https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> That sounds like the right thing to do, so I installed the attached patches 
> (the
> first one just documents the need for xz support).

Thanks for all your recent patches!

> I also tagged the v3.4 commit; somehow that tag wasn't pushed into Savannah 
> when
> 3.4 came out.

Tagging is a hard-to-avoid part of the release process, and it did
indeed tag a commit with v3.4:
7aa77dd6ea378c1e528e276761617b7dab411d2e, and it was pushed (per an
auto-generated email I received), but there was a minor snafu: you
were pushing a change precisely while I was making that release, and
your change (7bec6b13ce4dc01bb50b7fa682e3b77778562399) landed between
when I'd published the tarball and when I would have pushed the
release commit. Once your commit had landed, I had a dilemma, since
the commit I tagged (which records the contents of the tarball) did
not include your doc-updating commit, which one might now assume is
part of the 3.4 release. I considered/rejected these options:
- redo the process with a new release number and skip v3.4
- revert your public commit

Instead, I opted to live with the disconnect. I think I merged the
NEWS-modifying commit to fit on top of yours, then pushed, thinking
3.5 would come soon after, and then all would be back to normal. Until
then, "git describe" made it look like version 3.3 is the latest
official release.

With all your fixes, I think we're at a good point to release 3.5, so
I'll publish a prerelease snapshot shortly.