Re: No longer supply SHA1 checksums for new releases

Julian Foad wrote on Mon, 13 Aug 2018 13:32 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> > > * stop producing *.sha1 files and stop listing SHA1 on the 'downloads' page
> > >
> > > -- http://svn.apache.org/r1837939
> >
> > I was under the impression that we should keep producing *.sha1 files
> > for 1.9 and 1.10 releases, for compatibility reasons. The "SHOULD NOT"
> > language in the policy was specifically intended to allow this sort of
> > compatibility.
> >
> > To be clear, I'm suggesting that we only drop sha1 checksums for 1.11.0-alpha1
> > and newer. WDYT?
>
> Sounds good. I suggest for the time being we should achieve this by
> using a pre-r1837939 revision of trunk/tools/dist/ when running
> 'release.py' for 1.10 and older patch releases, and manually tweak the
> result as necessary, such as omitting the SHA1 column from the
> 'downloads' page.
>
> If any future changes to release.py begin to make this approach
> impractical we can revisit it then.

I would say that _anything_ that requires the RM to remember to make a
manual step that isn't in the "Rolling a release" runbook is
impractical. In particular, requiring the RM to run an old version has
two problems:

1. The RM is liable to use the HEAD version as per normal procedure.

2. If patches that are added to HEAD in the future will be required for
   rolling 1.10 versions too, the RM will have to do merges and possibly
   conflict resolution before being able to roll a release.

We can solve #1 by adding a fast-exit path, e.g., something along the lines of ---
.
    if version < Version(1,11,0):
        sys.exit('Revert r1837939 locally and remove this if block before rolling pre-1.11 versions')
.
--- but that wouldn't solve #2.

Correct me if I'm wrong, but wouldn't reverting the first hunk of
r1837939 and making it conditional upon a 'version < Version(1,11,0)'
check be all we need to do to have release.py generate *.sha1 files for
1.10 and earlier only, but not add sha1 info to emails and download
pages for any future release? See attachment.

Cheers,

Daniel