Clangd is part of LLVM, which means clangd 12 is built from the LLVM 12 sources.
The way this works is:
- twice a year (roughly January + July) the llvm/llvm-project source is branched from main (e.g. release/12.x)
- a release candidate is built
- people find important bugs (either in the RC, or independently) that should block the release. Fixes get committed to main and cherrypicked into the release
- a new release candidate is built
- (repeat for months until the RC looks good)
- eventually one of the RCs is tagged final
if most users are using the latest official clangd release, and clangd releases are tied to LLVM releases which are every 6 months, does that make the velocity at which new features are rolled out to clangd users a bit on the slow side?
Yes. Especially since we're seeing a 3-month delay from branch to release these days, it means the median time from commit to release is 6 months. And then if they're installing via a distribution (e.g. debian) there's often some further delay before that becomes the default, and there's likely often some delay on the user end. My rule of thumb is it takes around a year for a feature to land to most public users.
This is a big cost, there are some practical advantages to being on the llvm release cycle:
- it's pretty important that we don't ship a crashy version of the clang parser, and the stable branch of clang is almost always much better than master. (Every release cycle we get clang crashers cherrypicked into the release branch)
- we do find & fix clangd regressions fixed on the release branch too
- we can be pretty casual about features in an intermediate state if a release isn't being cut soon
- we piggyback on a lot of packaging, testing, distribution infrastructure
- debian packages can use dynamic binaries sharing clang libs with the toolchain in the usual way
- we get along with the rest of the llvm community better if we don't diverge too much :-)
There are alternate models possible, with tradeoffs:
- Google's internal clangd releases are a couple of weeks behind HEAD. This is a static binary, and uses llvm versions where clang has passed a bunch of internal testing. We have to roll back sometimes, which is easier in a managed environment.
- as an out-of-tree project, we could build releases with the latest version of clangd code + the last stable release of clang. Giving up version-lock with clang makes it harder to make cross-cutting changes, we can't be in LLVM CI so we'll get more regressions and big-bang version upgrades, etc. I think CCLS works this way (with #ifdefs to support multiple LLVM versions)
- we can simply accept the above issues and release static binaries from HEAD (that's what our github snapshot releases are, and most of them are okay!)