Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks, I think having this is super useful!
| llvm/docs/HowToReleaseLLVM.rst | ||
|---|---|---|
| 53 | Why not a rough date like for the even ones, instead of 4th Tue? | |
I think "Week number" is too ambiguous to be a guide. If January starts on the last day of the week, does that still count as week#1? What day does the week start on, anyway--much of the world starts the week on Sunday, much of the world starts the week on Monday.
"Fourth Tuesday in January/July" is unambiguous and makes everything easier to plan. Using "Start + N weeks" for the rest of the target dates is fine.
The whole table is meant to be a guide and not exact. I like having the approximate calendar dates, because I think this is the most informative for non-release managers. The week numbers are really meant for the release manager, but I would be fine replacing those with deltas (e.g. + 4 weeks) if you think that made more sense.
I'd expect the pace of preparing the release to be basically the same regardless of start date, so the milestones would make more sense as start date plus N weeks.
If you want wiggle room for the start date, that's fine, anything that expresses "late January" and "late July" will work. I thought it was going to be more definitive, what with specific week numbers and all.
+1. I am not sure if it is worth to publish this detailed release plan as the schedule is quite optimistic. I dont see an extra value if the LLVM would miss all deadlines anyway.
It's helpful for the release managers to have at least have a target date for creating the release branch and also to know how much time to wait between -rc1 and -rc2. I think we should have this information at a minimum, but I agree after -rc2 the release schedule does become unpredictable. I'll try to rework this, so it is less specific.
| llvm/docs/HowToReleaseLLVM.rst | ||
|---|---|---|
| 53 | Actually, I'd prefer relative Tuesday for both processes. Otherwise we'd eventually start on weekends... First date is relative to month (4th Tuesday) and the following are relative to first (2 weeks later, etc). Specific dates make no sense to me. I'd also say "at least N weeks", perhaps even also "at most N+M weeks". Having specific dates or non flexible time frames will cause people to complain on the list when things don't go according to plan, pointing out our documentation and saying, with reason, that we're not following it. | |
FWIW, I think this would be incredibly useful as a guideline. I don't care whether the dates are exact or not, and how dates are expressed. However, it would be really useful for folks working towards a release to know when the branch is going to be cut, since that effectively corresponds to a deadline for their work.
For example, we've been trying to push large libc++ features in LLVM 15, and knowing roughly when the LLVM 15 is going to be cut would have been really useful in scheduling various things on our side.
Update the schedule to be more concise. I included a definitive date
for the release branch since this seems like the most important deadline
for most people.
| llvm/docs/HowToReleaseLLVM.rst | ||
|---|---|---|
| 65 | how do we get to 4 weeks here? is it 4 weeks since the first RC until release? In that case it should be 6 weeks I think? | |
I'm really happy with this, I think it documents an essential aspect of LLVM releases that was not clearly communicated in the past.
| llvm/docs/HowToReleaseLLVM.rst | ||
|---|---|---|
| 65 | Yeah, I think it makes more sense to say that testing is 6 weeks, since concretely testing will happen during the entire period between the branch point and the -final being tagged. | |