Hi,
Here is the proposed release schedule for LLVM 15.0.0:
I will post this on the website in a few days if there are no objections.
v2
As noted in the LLVM 14 retrospective, I think 2 RCs is really low (we had 4, 4, 5, 6, 6 for the last releases), especially if there are no procedural changes to support this change while ensuring the quality of the release, as well as very loud communication that people should prioritise any planned RC testing ASAP (ideally reaching e.g. someone expecting 4-5 RCs who thinks they can push off testing until rc3).
I don’t think we should cater excessively to people who early RCs, but it does seem a bit odd to have RC1 and RC2 more than two weeks apart (the normal point release cadence).
As a maintainer of FreeBSD packages (as opposed to the base system compiler maintained by @DimitryAndric), I generally find build or packaging issues in RC1 so would like RC2 to follow fairly promptly so I can ditch what ever hacks I put in get RC1 out while I still remember the context.
That’s completely fair, though my key point about that was that trying to change the ingrained expectations (based on previous release cycles) will almost certainly make us run into this.
PS. Also in favour of higher cadence of RCs, though that would probably need more build artefact automation to keep the work for release testers/builders manageable.
We usually only plan for 2 or 3 RCs, but end up doing more out of necessity. I agree with @brooks that 4 weeks between release candidates seems long. What if instead we did -rc2 on Aug 9 and -rc3 on Aug 23?
Works for me
I should inform folks that the C++ plenary (which is when most of the remaining features of C++23 will be voted in officially) is on July 25, so a day before the the LLVM 15 branch.
I do not think this is an issue but i thought I would point it out.
I’ll make some changes (removing extension warnings for a few features that should be approved) ahead of time
The planned list of proposals is here https://github.com/cplusplus/papers/issues?q=is%3Aissue+is%3Aopen+label%3Astraw-poll+
That seems good to me - perhaps to help ensure things converge quickly enough after rc1, you could post a reminder (in this thread or a new one) ahead of the branch? At least one reminder 2 weeks ahead of time, but one at T-2 weeks and another at T-1 week would make sense to me.
@cor3ntin It should be OK to make these changes in the releae/15.x branch to up to -rc2. Just file backport requests for the changes you want in the branch.
@asb Yes, I can do reminders, good idea.
I’ve just updated the release schedule v2 with the suggestions from this thread.
Looks great!
I missed the RC window for 14 but will make sure to make it in time for 15. This does mean however that we (the zig project) have some regressions already lined up from 14, such as this one. I am not able to move this into the milestone yet; still waiting to hear back from Chris Lattner about getting GitHub permissions activated.