This is an archive of the discontinued LLVM Phabricator instance.

HowToReleaseLLVM: Add annual release schedule template
ClosedPublic

Authored by tstellar on Jan 20 2021, 9:54 PM.

Diff Detail

Event Timeline

tstellar requested review of this revision.Jan 20 2021, 9:54 PM
tstellar created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 20 2021, 9:54 PM
hans accepted this revision.Jan 21 2021, 1:04 AM
hans edited reviewers, added: hans; removed: hansw.
hans added a subscriber: hans.

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.

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.

sylvestre.ledru accepted this revision.Apr 4 2021, 9:22 AM

I am not opposed to this. I am just afraid that we will miss all the deadlines :)

This revision is now accepted and ready to land.Apr 4 2021, 9:22 AM

I am not opposed to this. I am just afraid that we will miss all the deadlines :)

+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.

sylvestre.ledru resigned from this revision.Nov 23 2021, 5:20 AM
This revision now requires review to proceed.Nov 23 2021, 5:20 AM
rengolin added inline comments.Nov 23 2021, 6:22 AM
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.

Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2022, 2:12 PM
tstellar updated this revision to Diff 447805.Jul 26 2022, 12:50 PM

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.

thieta added a subscriber: thieta.Aug 9 2022, 6:26 AM
thieta added inline comments.
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?

ldionne accepted this revision.Aug 9 2022, 11:20 AM

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.

This revision is now accepted and ready to land.Aug 9 2022, 11:20 AM
tstellar updated this revision to Diff 451272.Aug 9 2022, 2:21 PM

Fixup some outdated information.

tstellar marked 2 inline comments as done.Aug 9 2022, 2:21 PM
thieta accepted this revision.Aug 10 2022, 12:09 AM
This revision was automatically updated to reflect the committed changes.