[RFC] Centralized location for version information


I have now done two bumps of the version information in the repo and have come to the conculsion that it sucks. I had to update a lot of places and forgot some of the places. So I wrote a script to automate this and uploaded it here: :gear: D133923 [Release] Add bump-version script. (llvm.org)

In that discussion more people chimed in and said that maybe the solution is to centralize the version information in all the different build systems, so instead of storing the version in CMake, Bazel, GN and Lit we would read version info from a single file.

My suggestion is that we add a top level VERSION or VERSION.txt file. Would that be possible in GN and Bazel? I know I can do the changes in CMake and lit to fix this, but not sure of the other systems.


The file would have to be part of the llvm/ directory, not the top level, otherwise this would break standalone builds. The lit version likely also can’t be derived in this way, because lit is also shipped as an independent python package (e.g. on pypi), though I’m less sure on that point.

If cmake, bazel and gn can all derive the version from a single llvm/VERSION file, that sounds reasonable, but I don’t know to what degree that is technically feasible.

I think technically we shouldn’t have to worry about GN or Bazel since CMake is the only officially supported build system. (Bumping them is of course nice, but I think that should be considered a courtesy.)

The ones I always found hard to remember were lit, libcxx, and the various Sphinx docs (no longer a concern after e80c52986e1bb3afa6a92c58b1cb897877923a66.

I think the best solution would be if as much as possible just pulled the version from the CMake files. Having a script is second best I suppose. When I did version bumps I always just looked at the previous version bump commit and copied that.

If people are not interested in changing it or accepting the script upstream I can just keep it locally to help me. But if we want to bring on board other people to do releases it’s nice to have the script as a form of documentation instead of having to dig through the log.

It can also be a way for third-party build systems to update the release managers when they change anything. We can say “read version from cmake or change this script and it will be bumped”.

I didn’t mean my comment to come across as being against having a script. Clearly having a script to update the versions is much better than the current situation.

Ah good. I misread your comment. Yeah I think it’s worth merging the script for now and we can always update the script if we change anything on the backend.

@tobiashieta I wouldn’t worry too much about this problem. The release team is in control of the creation of the tarballs that get used for the standalone builds. I think it should be possible to add the a version file to all tarballs. Afterall it would help us IMHO. At least that’s what I experienced when creating the source tarballs for the daily Fedora LLVM snapshots.

@serge-sans-paille can you enlighten us how difficult it would be to consume the version from a file rather than a config in some script?

This will introduce additional failure points that don’t seem justified. Both release tarball generation and consumption of the version file from cmake/lit/etc will have to be special cased if it can be located either in the root directory or the subproject directory based on the build type. Having it in the llvm/ directory should “just work”, and I’m not sure what additional benefit we get from having it in the root directory in particular. (Note that other subprojects already consume the version via LLVM cmake files.)

You’re right. Then I have another idea. @tobiashieta when you’re doing the release number changes, wouldn’t it be a good idea to have a top-level version file but instead of having it just there, copy it to all places where it is needed and consume it from there? Then the version is

  1. Accessible from everywhere.
  2. Easy to change because you just need to copy the file to the right locations. That’s a simpler mechanism than your script at least.

It doesn’t solve the problem of a single place to store the version but at least the distribution of the version becomes simpler, no?

That would be unconventional for a python package, but we could do something like

  1. if we are building in-tree, fetch the version from top-level
  2. if we are generating a package, copy the top-level version in the package tarball

Just want to echo @hansw2000 that while updating the alternative build systems (Bazel and GN) is nice, it’s not something that release managers or the community at large should have to worry about. It is certainly possible for Bazel to consume the version from a text file, and I suspect the same is true of GN. I was struck by how many different places had version numbers when setting up the Bazel build, so would welcome this being centralized a bit more.

I think conceptually it would make more sense for the version number to be at the top level rather than nested inside the llvm/ directory. Having general project things inside the llvm/ directory looks to me like a holdover from SVN. We discussed this when deciding where to put the Bazel files and agreed that it made more sense to have them in the top-level utils/ rather than llvm/utils/ despite the precedent. That said, if it complicates releases, that may override those concerns.

1 Like

Yeah I agree it’s not mandatory, I am just being considerate :slight_smile:

I will work on the script and see if I can get it merged, I hope GN and Basel developers can help keeping that script up-to-date when changes are made.

Then I hope we can make the version more centralised in a near future. But I probably won’t be able to handle that transition in all build systems - I really don’t have bandwidth learning Bazel as well!

1 Like