[cfe-dev] LLVM 10.0.1-rc1 release update

[Jerry Scharf via cfe-dev]

On 5/18/20 10:27 PM, Tom Stellard via cfe-dev wrote:
> Hi,
>
> 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.
>
> -Tom
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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.

background:

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.

jerry