Hi,
The release/15.x branch has been created. If you would like to backport a patch to the branch, please use the instructions here. The goal is to stablize the release branch over the next few days so we can release 15.0.0-rc1 on Friday.
-Tom
The URI seems to point the wrong place https://here
Thanks, I fixed it.
Downstream report from the Zig project:
- The stage1 compiler is now upgraded to opaque pointers API
- The self-hosted compiler is now upgraded to opaque pointers API
- Regression identified: x86 fpext half to fp128
We’re blocked on this regression; it is likely that once it is fixed, we will find many more regressions.
I noticed that release candidate 2 is tagged, however there are still 19 open issues in the milestone.
There are a lot of failing tests in the zig test suite in the llvm15 branch. I have been waiting until more known regressions from the milestone are fixed before doing further investigation, otherwise I risk wasting everybody’s time reporting already-known regressions.
Why cut the release candidate so soon, when testing rc1 has already uncovered so many issues? What is the purpose of rc2 when the issues found from rc1 are not solved?
We cut RC releases every second week and it’s to make sure that we give the release testers time to verify that all fixes that have been merged work, if we approach final with a lot of open issues we might do another RC at that point depending on the severity of the issues.
The process is documented here: How To Release LLVM To The Public — LLVM 16.0.0git documentation
@tobiashieta I think the page you linked says
- Tag bug fix -rc1 after 4 weeks have passed.
- Tag bug fix -rc2 4 weeks after -rc1.
Isn’t “every second week” just the cadence for the minor releases? (i.e. 15.0.1, 15.0.2 etc).
Personally I also think rc2 came a bit too soon. There’s still an open build issue on armv7, which I only managed to request a backport for this morning. I’m not saying the whole community needs to wait for me to fix armv7 before moving on, but in my experience rc1 for the major release often takes a bit more work than the follow-ups. So 4 weeks for rc1 sounds better to me. Just my 2 cents, I’m not saying you should retract rc2 ofc.
Just to add some further background, the 2 week cadence was proposed and discussed here.
1 Like
Ah when looking at that page it’s probably not up to date. The release schedule posted on llvm.org shows a two week cadence.
I think it’s hard to dial in the right period and “how many open issues are acceptable”.
I think the current 2 weeks policy was born from the fact that it took too long to get fixes in and delays made it impossible to know when a release was “ready”. Since llvm is so big and diverse the answer will probably also be different for different people.
Let’s continue on with 15.x as scheduled by Tom and we can have a retrospective after that to discuss if we want to tweak the next schedule.
Right, would be nice if someone could go over the release-related docs and update accordingly. Another suggestion I have is to link LLVM GitHub User Guide — LLVM 16.0.0git documentation from How To Validate a New Release — LLVM 16.0.0git documentation, so it’s easier to find (I don’t have time right now to send a patch myself).
I’ll try to get to it.
Proposed patch to update the documentation with the current schedule that we are using.
Thanks for the discussion, all.
I noticed that release/15.x branch has a bug fix in it after rc3. Does that mean we should expect an rc4?
At this point I am not expecting a rc4 - I am very careful with the changes I take at this point - but we will see by the end of the week.
Shouldn’t the final release get the same treatment as an rc, that is be a normal merge window for patches? I don’t think LLVM ever followed a process where the final release should be equivalent (or even particularly close to) the last release candidate.
I think this makes especially little sense when taking into account the new release process for patch releases, which no longer go through release candidates at all. If a patch is good to go into 15.0.1, then IMHO it should be good to go into 15.0.0 as well (purely based on submission timing, not other considerations), and patches after rc3 should never be cause to introduce an additional rc (it’s a time-based process).
Right now - final is getting almost the same treatment as a rc, I am just a little more careful not taking to big changes or non-critical fixes. Is that overly conservative of me? Maybe, but I am also trying to navigate this and there are no hard and fast rules.
I think the argument for trying to slow down the patch merging before -final makes sense so that there is not a huge batch of changes between rc3 and final. Is there a difference between 15.0.0 and 15.0.1 in this case? Not sure, but punting some fixes now right before final to 15.0.1 gives them more testing in main at least, which I think is pretty good.
Happy to hear feedback if I should modify this approach or not. I will most likely collect feedback after the 15.0.0 release so we can collect all discussions in one place and see how we can evolve the process for the next release.
This is very uncommon for LLVM releases.
As pointed out: Tag/Release rc4 and then make a final.
Background:
I got a “strange” github-notification this morning and thought is that real or not?
( Hope there are no rc3 relicts in any release-relevant files. )
Hope we will see an official announcement, soon.
Anyway, walk a different way…
[1] LLVM 15 release cycle · Issue #1678 · ClangBuiltLinux/linux · GitHub
I am not sure what you are referring to here. Can you explain what your question is?
As said this morning I got a github-notification:
github-actions[bot] notifications@github.com
[llvm/llvm-project] Release llvmorg-15.0.0 - LLVM 15.0.0
Normally, I got such notification from a real person like Tom Stellard.
Might be that changed.
An rc4 gives all the LLVM arch maintainers a time to verify their builds are OK.
They report back and a final was tagged (might be the same git-hash as rc4 as an example).
( This morning I found a post in disclosure/release-testers where Sylvestre pointed to issues with rc3 - cannot say Debian-specific or not. Hope, this is fixed. )
Might be that RC versioning changed with…
Anyway, there will be 15.0.1, 15.0.2, …, so no big story for me.
If you go new ways (BTW, I like that :-)), please explain.
That helps people to understand (and accept).
I don’t think anything has changed - if you read @nikic message above we never made sure the last rc is the exact same as the final release since the 15.0.x is coming soon. The final release is handled as any RC release unless there is some major issue (we can’t catch all issues LLVM is to big) which make us postpone the final version.
The github-actions bot have done the notifications since 14.x at least (it was broken for the -rcS because my name was not in the whitelist so I had to handle it manually until the final version).
You can always verify the release is correct or not by the GPG signature on the tag - the keys are listed on https://releases.llvm.org.
Hope that explains it.