llvm dev - Jul 2021 - RFC: Update LLVM_VERSION_SUFFIX CMake variable for release candidates

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.

Ensuring that the SONAME's change when the library ABI's change is
the main motivating reason for proposing this change.  However,
I think in general it is also better for the project to be able to
distinguish between release candidates and final releases.

Note that clang does not currently include LLVM_VERSION_SUFFIX in its
--version output, and I'm not proposing change this as part of this
RFC.

- Tom

On Tue, Jun 29, 2021 at 10:39:01 -0700, Tom Stellard via cfe-dev
wrote:
> 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 ""
Just a note that this can be confusing because there would now have
builds reporting as `13.0.0-rc1` without any corresponding tag in the
repository. I think that instead of doing that, changing it to be
`13.90.0` or something to indicate "after 13, but not yet 14" while
avoiding any (plausible) `13.x` release number might be a better
strategy.

I learned this trick from KDE by the way if any prior art is wanted.

(Just an outside observer, FWIW.)

--Ben

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 
isn't.

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.

Cheers,
Harald van Dijk