LLVM 17.0.0 tagged, but with a mistake


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:

  1. Leave it be and announce it in the post that the version is wrong and that people can pick up this commit Remove RC suffix · llvm/llvm-project@01f8ba7 · GitHub if they want it fixed.
  2. tag llvmorg-17.0.0_1 or something similar with the fix and change the GitHub release to point to this tag instead.
  3. tag llvmorg-17.0.1 and just go ahead with that as our final.

Any preferences?

I’d go for 1. or 3. Rather not start using some weird tags/version numbers as in 2.

Do you think it’s worth fixing with 17.0.1 for you?

If you build llvmorg-17.0.0, what is the output of clang --version?

It doesn’t include the suffix there specifically, but it seems like some tools are using it.

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.

I think I’ll just roll a 17.0.1 - seems like the safest way forward. Sorry for the churn everyone.


17.0.1 is now tagged - please go test this version instead of 17.0.0!

I have removed the 17.0.0 release from the github page.

Don’t be sorry. And thanks again for the work :slight_smile:
As release managers, I think we all have made this kind of mistake at some point (i stopped counting for myself)


Windows is ready. Hashes:

C:\src>certutil -hashfile llvm_package_17.0.1\build32\LLVM-17.0.1-win32.exe sha256
SHA256 hash of llvm_package_17.0.1\build32\LLVM-17.0.1-win32.exe:
CertUtil: -hashfile command completed successfully.

C:\src>certutil -hashfile llvm_package_17.0.1\build64\LLVM-17.0.1-win64.exe sha256
SHA256 hash of llvm_package_17.0.1\build64\LLVM-17.0.1-win64.exe:
CertUtil: -hashfile command completed successfully.

These were built with

llvm-project\llvm\utils\release\build_llvm_release.bat --version 17.0.1 --x86 --x64

At beb339c0ef8b0971fbb461d8a041a7514e0e5804 (same as the last release candidates).

1 Like

PowerPC Linux tarball uploaded. There were no issues.

59094dbadb4f0635c2ffb9bd87176fee28ebc6ed  clang+llvm-17.0.1-powerpc64le-linux-rhel-8.8.tar.xz
1 Like

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.

I’m sorry if this is offtopic for this thread but why don’t we use Github Actions or any other kind of automation to built the release binaries?

1 Like

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. :slight_smile:

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.

Is the cross-compilation an option?

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.

P.S. This could be a GSoC project, I guess.

The release process uses a three stage build - that might complicate things a bit. It’s definitely doable but probably more challenging than it seems.

I’ve now uploaded the Solaris/amd64, Solaris/sparcv9, and Linux/sparc64 tarballs:

153b8b650705390cc3b4ff739b061f5bff87542531c002c039d52c00781559f7  clang+llvm-17.0.1-amd64-pc-solaris2.11.tar.xz
0ab5f6a9b19ec968628d987d9430a033801c78bee65fbf40c72da660ff401f4d  clang+llvm-17.0.1-sparc64-unknown-linux-gnu.tar.xz
a69d47bb1397766a87fcdef28260fc664fdf9b6e1f7c56792939baf8513c1694  clang+llvm-17.0.1-sparcv9-sun-solaris2.11.tar.xz

No regressions relative to rc4.

1 Like