I have just tagged 17.0.0 final. Unfortunately I tagged it and forgot to remove the rc suffix in the CMake file. This means that llvmorg-17.0.0 would build with a version that denotes it to be a RC unless you manually specify LLVM_VERSION_SUFFIX.
Before I announce this version to the public I wanted to get your opinion on what to do:
It’s certainly easier to handle than manually applying a patch. Given the increased cadence of micro releases these days, I wouldn’t consider it a problem. But that’s probably better asked off the distro builders.
Don’t be sorry. And thanks again for the work
As release managers, I think we all have made this kind of mistake at some point (i stopped counting for myself)
Are you planning to include a build for Windows on ARM? I don’t see LLVM-17.0.1-woa64.exe.
This question was asked on the announcements thread and it beautifully illustrates this skew between the different audiences for the LLVM releases.
The release announcement is made to the public and that’s how “release testers” find out about it. Some very large part of the public only cares to use the binary releases of Clang + LLVM that are produced after tagging is done. And it seems pretty natural to look for those binaries when the release is announced. But - they’re not there! … yet…
And while we all try to produce releases in a timely fashion, some of us (ok probably it’s just me!) don’t get it done for a day or more afterwards.
I’m pretty sure this has come up before, hasn’t it? Do we want to handle release announcements differently to avoid this confusion/let down?
As long as release artifacts are built by volunteers, and these people have limited time and resources, I think you cannot guarantee there will be a consistent set of those artifacts for every release.
For example, I usually build the macOS artifacts, and whenever possible, FreeBSD artifacts, but currently I am occupied with other things so I don’t have time. (I hope to put up something relatively soon but it might take a while.)
Other release testers/packagers might have different reasons for not being able to (quickly) provide artifacts.
I would suggest that at some point, the llvm project should invest some time in making official CI builds, then you could use that infrastructure for building releases too. But still you would likely be limited to a certain list of OSes and versions, and cannot make every possible user happy.
Yeah. One thing we could do is to tag the release a few days before the announcement, but I bet that will lead to a lot of “the tag is on GitHub, where is the announcements”.
I should maybe just always be clearer in the post that binaries will be available after a few days.
In this case, an LLVM-17.0.1-woa64.exe is likely to be built. But it will “never” be built by the time the eager users who are subscribed to announcements click on the published links. At the time of the user’s question only one target’s release actually had been uploaded.
I would suggest that at some point, the llvm project should invest some time in making official CI builds,
Yeah, I agree - that would probably take the heat off a bit. It’s been discussed in the past.
Pretty simple really: it takes a non-trivial amount of effort to pull that off. Setting up proper CI is always much trickier than it seems.
Preferably a plan should be written up by somebody who is familiar with GitHub CI’s properties and quirks, so there aren’t any pitfalls. Also, it could very well be that GitHub CI is not up to the task, for example if it does not support the various OSes we have been building for until now. So in that case, other CI providers need to be considered.
According to this page, Github Actions provides Ubuntu, Windows and MacOS runners:
But they all run on x64 – but still would allow to offload some work to the automation.
Also, any other Linux-based OS should be available through Docker.
So, building all the possible combinations of OS and CPU Architectures could be done with the Github Actions runners and the cross-compilation, but I’m not sure if it is feasible.
