-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[llvm][release] Add links to automatically built packages on release page #147021
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…page This adds links to the release packages that are automatically built using GitHub, so that users of those platforms can find them more easily. The approach taken: * "LLVM x.y.z Release" becomes the title for this links section. * No hand built files are linked to because we can't be sure when or if they will appear. It's better that users check the full file list if they need those. * This means no Windows links, but I've specifically mentioned Windows just below the links to mitigate this. * I have tried to use the vendor names for the architectures, that casual users would recognise. * Their signature file is linked as well. I expect most will ignore this but better to show it to remind people it exists. * I called it "signature" as a generic term to cover the .jsonl and .sig files, but we're not linking to any .sig files yet. I considered generating this using a lot of templates, but considering the small number of links and how useful it is to see the layout in the Python file, I prefer writing it out. We could link to all files that *usually*, *eventually* get built, but I'm not sure how misleading that will be for users. So I'm proposing this conservative version for now.
I went through some of the most popular projects on GitHub and most of them sidestep this by having very few packages, or their GitHub release is just a source archive and you get binaries elsewhere. I did find https://github.com/rustdesk/rustdesk/releases/tag/1.4.0# which does a similar thing using a table, but I found a list easier to navigate, and a table would have large gaps if we listed all of our major packages. "I am a user who has a <mac/linux> machine powered by and I want to download llvm" is the use case here. |
* [Apple Silicon](https://github.com/llvm/llvm-project/releases/download/llvmorg-{release}/LLVM-{release}-macOS-ARM64.tar.xz) (ARM64) ([signature](https://github.com/llvm/llvm-project/releases/download/llvmorg-{release}/LLVM-{release}-macOS-ARM64.tar.xz.jsonl)) | ||
* [Intel](https://github.com/llvm/llvm-project/releases/download/llvmorg-{release}/LLVM-{release}-macOS-X64.tar.xz) (x86-64) ([signature](https://github.com/llvm/llvm-project/releases/download/llvmorg-{release}/LLVM-{release}-macOS-X64.tar.xz.jsonl)) | ||
|
||
For Windows, and any other variants of platform and architecture, check the full list of release packages at the bottom of this release page. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"this release page" not "this page" because sometimes this text will be seen on the page that lists all the releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add the links commented out and then have the job that builds the binaries uncomment the links when the builds are done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, I think #147719 would do that. Not tested it just yet.
This adds links to the release packages that are automatically built using GitHub, so that users of those platforms can find them more easily.
The approach taken:
I considered generating this using a lot of templates, but considering the small number of links and how useful it is to see the layout in the Python file, I prefer writing it out.
We could link to all files that usually, eventually get built, but I'm not sure how misleading that will be for users. So I'm proposing this conservative version for now.