[llvm-dev] LLVM 9.0.0 Release

[Zach van Rijn via llvm-dev]

On Thu, 2019-09-19 at 15:56 -0700, Tom Stellard wrote:
> ...
> We did 7.1.0. and 8.0.1 releases on GitHub as a test, since
> this is where we'll be hosting the binaries once SVN is
> retired.
> 
> Why do you need canonical download links?

In short, to avoid breaking or requiring additional logic in
scripts that may download or use the official release tarballs.

The SVN --> GitHub migration [0] document is an excellent start,
though I'd like to suggest the (continued?) release of signed,
non-GitHub-generated, official tarballs.

Will sub-project tarballs be released in the future, and/or has
a decision on GitHub-hosted sub-project mirrors been made [1]?
The key is tarball availability. Not everyone has large disks :)

Right now links like these work OK ('llvmorg-V' is the tag, or a
commit hash could be used in lieu of the tag):

https://github.com/llvm/llvm-project/archive/llvmorg-V.tar.gz

redirects to...

https://codeload.github.com/llvm/llvm-project/tar.gz/llvmorg-V

and

https://api.github.com/repos/llvm/llvm-project/tarball/llvmorg-V

redirects to...

https://codeload.github.com/llvm/llvm-project/legacy.tar.gz/llvm
org-V

except that in these cases, sub-projects are not available
separately as on the Downloads page for the historical releases.

That's approximately version 3.2 forward, requiring ~250-900MB
(or more) of disk space per version.

Other nits that could be picked (examples not exhaustive):

  * Renaming of 'clang-V' to 'clang-V.src' in 3.0 --> 3.1;

  * Renaming of 'clang-V.src' to 'cfe-V.src' in 3.1 --> 3.2;

  * Inconsistent availability of sub-project documentation;

  * Availability of both .tar.gz and .tar.xz (or other) formats,
    which changed between 3.4.2 and 3.5.0;

  * Tarball sizes are no longer listed after 3.3 --> 3.4;

  * Inconsistent availability of tarball signatures; and

  * Inconsistent availability of PGP key listings for above.

By the way, the GitHub links above don't have a Content-Length
header or checksum of any sort. I'd like to see this as well.

Also, between the two 'codeload.github.com' links above, the one
with 'legacy.tar.gz' includes 8 characters of the corresponding
commit hash in the filename, while the non-legacy one does not.

Some of these will necessarily be moot once the migration is
done, but I believe more consistency and some of this security
(ability to validate tarballs) will be welcomed by others.


ZV


[0]: https://llvm.org/docs/Proposals/GitHubMove.html

[1]: ...#read-only-sub-project-mirrors