[cfe-dev] LLVM 10.0.1-rc1 release update
Jerry Scharf via cfe-dev
cfe-dev at lists.llvm.org
Fri May 22 22:32:39 PDT 2020
On 5/18/20 10:27 PM, Tom Stellard via cfe-dev wrote:
> All the patches for LLVM 10.0.1-rc1 have been merged, and I'm just waiting
> for the CI jobs to finish. I will tag the release tomorrow if all
> goes well.
> Don't worry if you have a change that didn't make it into LLVM 10.0.1-rc1,
> there is still another month to merge changes before LLVM 10.0.1-rc2.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
I am mostly a lurker on this list. I hope my perspective is useful.
It would make much more sense to me to call them 10.0.1-10.0.6 and the
last one having an rc cycle and becomes 10.1.
I am one of those people who prefers the .n release when deciding when
to upgrade our product's toolchain. We have 700k+ lines of high
performance, snarly, heavily templated. and sometimes bad C++ code
written by many engineers of various capability over the last decade
(the last part accurate for most established appliance products.) Every
toolchain upgrade is an archeological effort in which we find things
that don't work any more (and often never worked right) and need fixing,
often with a rototiller. The last round was particularly nasty for us,
taking about 20 MM to complete. The last thing I want is a toolchain
that I don't have maximum confidence in.
Isn't one of the jobs of the release process to say "this is the next
stable release that we think the general user community can/should
upgrade to"? Given that there are no release candidates, how is someone
to know that 10.3 or 10.5 is safe to upgrade to? You may make the
developer process simpler, but I think this makes the end user (and
possibly distro folks) process more complex and require them to
understand that 10.1 is just a calendar event and not an indication that
this is a safe, reliable release to move to. I would think that at least
one cycle of rc where teams are all encouraged to build and test in
their own way to look for serious flaws would provide some increased
confidence that this is a safe choice. I appreciate the idea that
improving the CI is important, but even massive investments in CI (we
have teams and millions of dollars of committed to CI testing hardware)
are not a replacement for wider QA and release testing.
More information about the cfe-dev