[Release-testers] [llvm-dev] RFC: Update LLVM_VERSION_SUFFIX CMake variable for release candidates

Harald van Dijk via Release-testers release-testers at lists.llvm.org
Thu Jul 1 09:18:15 PDT 2021

On 29/06/2021 18:39, Tom Stellard via llvm-dev wrote:
> Hi,
> I would like to propose that we start using the LLVM_VERSION_SUFFIX
> CMake variable for release candidates.  For example:
> after the release/13.x branch is created, instead of changing
> LLVM_VERSION_SUFFIX from "git" to "", we would change it to "rc1",
> then after the 13.0.0-rc1 release is tagged, we would update the
> variable to "rc2", etc. Then right before the final release has been
> tagged, we would set it to ""
> The library SONAME's currently include LLVM_VERSION_SUFFIX, so this
> change will cause each release candidate to have a different SONAME
> for libraries.  This is correct for X.Y.0 releases, since it's possible
> for a library's ABI to change between release candidates.  However,
> for X.Y.1 releases, we do not want to modify the SONAME's at all, so
> the build system will need to be updated to accommodate this change.

This would mean that the so-called release candidate is no longer a 
candidate for release. Even if no problems are identified in 13.0.0-rc1, 
it is still guaranteed that 13.0.0 will be different from 13.0.0-rc1. In 
particular, this means if a distro were to do a rebuild against 
13.0.0-rc1, and then no further changes are needed and 13.0.0 can be 
released, the distro will still need to rebuild everything that was 
already built against 13.0.0-rc1 against 13.0.0. The fact that the 
SONAME changes also means it's possible that other projects adjust to 
wrongly account for the SONAME change in a way that happens to work for 
the release candidates, but not for the actual release, so testing with 
the release candidate suggests that everything is fine when in fact it 

I was working on changing my own testing procedures for my own system to 
handle the current release candidate structure, where I am in much the 
same boat as distros, except on a smaller scale. Currently, 
llvm-12.0.0rc5.src.tar.xz and llvm-12.0.0.src.tar.xz are different 
files, but the only difference is that the former extracts to an 
llvm-12.0.0rc5.src directory whereas the latter extracts to a 
llvm-12.0.0.src directory, the archives are otherwise 100% identical, 
down to the mtime of each individual file. I wanted to use this to 
create a build of LLVM+clang 12.0.1-rc3 that, if 12.0.1-rc3 turns out to 
be the final release candidate, will be bitwise identical to the same 
build of LLVM+clang 12.0.1 and there will be no reason to re-test 
anything that worked with 12.0.1-rc3 against 12.0.1, allowing me to 
avoid a further mass rebuild once 12.0.1 is released. Under your 
proposed scheme, this may continue to work for x.0.1 releases, I am not 
sure whether it would continue to work for x.1.0 releases, but it would 
definitely cease to be an option for x.0.0 releases. That seems a shame, 
because it means the release candidates will be less tested than they 
would otherwise be.

Harald van Dijk

More information about the Release-testers mailing list