HowToReleaseLLVM: Add annual release schedule template

[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?

[probinson]

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.

[tstellar]

In D95114#2512315, @probinson wrote:

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.

[probinson]

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]

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

[xbolva00]

In D95114#2668155, @sylvestre.ledru wrote:

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.

[tstellar]

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.

[rengolin]

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.

[ldionne]

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.

[tstellar]

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]

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]

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.

[tstellar]

Fixup some outdated information.

llvm/docs/HowToReleaseLLVM.rst

 The release manager will determine if and when to make a dot release based
 on feedback from the community.  Typically, dot releases should be made if
 there are large number of bug-fixes in the stable branch or a critical bug
 has been discovered that affects a large number of users.
 
 Unless otherwise stated, dot releases will follow the same procedure as
 major releases.
 
-The release process is roughly as follows:
+Annual Release Schedule
+-----------------------
 
-* Set code freeze and branch creation date for 6 months after last code freeze
-  date.  Announce release schedule to the LLVM community and update the website.
+Here is the annual release schedule for LLVM.  This is meant to be a
+guide, and release managers are not required to follow this exactly.
+Releases should be tagged on Tuesdays.
+
+=============================== ========================
+Release                         Approx. Date
+=============================== ========================
+------------------------------- ------------------------
+*release branch: even releases* *4th Tue in January*
+*release branch: odd releases*  *4th Tue in July*
+X.0.0-rc1                       3 days after branch.
+X.0.0-rc2                       2 weeks after branch.
+X.0.0-rc3                       4 weeks after branch
+**X.0.0-final**                 **6 weeks after branch**
+**X.0.1                         **8 weeks after branch**
+**X.0.2                         **10 weeks after branch**
+**X.0.3                         **12 weeks after branch**
+**X.0.4                         **14 weeks after branch**
+**X.0.5                         **16 weeks after branch**
+**X.0.6 (if necessary)          **18 weeks after branch**
+------------------------------- -------------------------
+
+Release Process Summary
+-----------------------
+
+* Announce release schedule to the LLVM community and update the website.  Do
+  this at least 3 weeks before the -rc1 release.
 
 * Create release branch and begin release process.
 
 * Send out release candidate sources for first round of testing.  Testing lasts
-  7-10 days.  During the first round of testing, any regressions found should be
+  6 weeks.  During the first round of testing, any regressions found should be
   fixed.  Patches are merged from mainline into the release branch.  Also, all
   features need to be completed during this time.  Any features not completed at
   the end of the first round of testing will be removed or disabled for the
   release.
 
 * Generate and send out the second release candidate sources.  Only *critical*
   bugs found during this testing phase will be fixed.  Any bugs introduced by
   merged patches will be fixed.  If so a third round of testing is needed.
 
 * The release notes are updated.
 
 * Finally, release!
 
 * Announce bug fix release schedule to the LLVM community and update the website.
 
-* Tag bug fix -rc1 after 4 weeks have passed.
-
-* Tag bug fix -rc2 4 weeks after -rc1.
-
-* Tag additional -rc candidates, if needed, to fix critical issues in
-  previous -rc releases.
-
-* Tag final release.
+* Do bug-fix releases every two weeks until X.0.5 or X.0.6 (if necessary).
 
 Release Process
 ===============
 
 .. contents::
    :local:
 
 Release Administrative Tasks