Sorry for the late reply, I’m on vacation right now and until the end of March. See my answers below.
“Users” are just going to use a toolchain distribution put together by someone else, right?
Yes, that would be my expectation too. I guess that depends how you define users.
I’d expect the person putting together such a toolchain distribution to download a release of llvm, and build all of the components from that same revision. It’s historically been annoying to ensure that you actually build the runtime libraries using the just-built clang, when you’re building a set of llvm+clang+compiler-rt+libcxxabi+libcxx all together, instead of whatever compiler you had lying around…but once the documentation and process is updated to make the right thing happen in the “obvious” path, ISTM that solves 99% of the problem here.
I agree, I think this solves 99% of problems.
For developers of libc++ who are making changes against devhead, they may want to avoid rebuilding clang every time they want to test a new revision of libc++. For that, the “last stable” promise seems useful. But that seems like it shouldn’t really affect users?
The question is whether there’s circumstances in which someone who is putting together a toolchain distribution needs to upgrade to a newer version of libc++, yet remain on an older release of clang (…but only up to 1 year old). If that’s what folks are saying is necessary: maybe someone can help explain why? It doesn’t seem like it should be needed, to me.
This is useful if you ship libc++ as part of a different product than the product you ship Clang in, yet both need to interoperate. For example, we do this on Apple platforms by means of shipping Clang in Xcode, but shipping libc++ as part of the operating system and corresponding SDK. In this case, the “last stable release” guarantee means that everything will work as long as Clang keeps getting updated at a reasonable rate.
I think it’s reasonable to raise the compiler version floor for libc++, but I think I would like to see a more relaxed policy with respect to clang. Maybe the last two releases of clang, so that a user of ToT libc++ with stable clang doesn’t have to rush to upgrade clang as soon as it is released. If you support the last two releases, the user always has six months of lead time before updating, and libc++ never supports a compiler older than a year.
Hmm, yes, I think that would make sense. This would indeed give more leeway to folks testing ToT libc++ with a released Clang, so that they wouldn’t need to update the Clang on their CI fleet the very second a new Clang gets released (if they don’t, the next libc++ commit could technically break them). I think that makes sense - at least we can start with that and see if we want to make it more stringent in the future.
I’ll be creating a Phabricator review to enshrine this updated policy when I come back from vacation, and it will start being enforced at the next release.