Incorporate draft release notes into relnotes generation at release time about release

[david-mcmahon]

Some options:

• Detect the draft in CHANGELOG.md and update it
• I earlier suggested building up the draft release notes in the wiki and then publishing (at release time) directly from there (scripted).
  • This provides the additional benefit of ease of editing and submitting and visibility on the lead up to the release
  • Easy to automate API to extract formatted text from wiki

[david-mcmahon]

Czars and release notes maintainers past and present, please make your preference heard or make alternate suggestions.

[pwittrock]

Using a gist or wiki page and requiring an argument which is the link to the release notes SGTM

[erictune]

Wiki would be fine.

Need to clarify in what the exact logic would be.

• Does wiki contents get injected in between the "Downloads" and "Previous Relases included In" sections?
• Why is there no "Changelog since" section in the minor releases, and is one needed and if so how does it work.
• Should "Features" section be generated (@spiffxp what do you do?)

[spiffxp]

I used a pre-release version of https://github.com/github/hub and used the hub issues command with a pile of bash to generate a starter list. Updates were made manually since then.

for phase in alpha beta stable; do
  echo "## $phase"
  echo
  hub issue -l $phase-in-1.4 -f \
    "- [%t](%U) (kubernetes/features%i, @%au, %as)%n";
  echo
done

One of the confusing things was that I couldn't just look at the v1.4 milestones, since some feature owners had bumped them up to v1.5 to track the next iteration, eg: planning to have an alpha-in-1.4 feature turn into a beta-in-1.5 feature. Instead, I had to look at the alpha-in-1.4, beta-in-1.4 and stable-in-1.4 labels. IMO this would be way less confusing if there was one-issue-per-discrete release... eg: rather than seeing the same issue get bumped across 3 milestones as it evolves from alpha to beta to stable, have one issue for alpha, one for beta, one for stable.

agree with @david-mcmahon wiki would be a good idea, use the features repo for this, to get a PM perspective up front. I should have been able to get my one line summaries from some part of that repo instead of a spreadsheet, as much as I really appreciated the cat-herding that took.

Then, use the existing automation and labels to get more detailed technical cluster-ops-facing info.

I liked that we started this process a full week before the final bits got cut. I would encourage us to aim to have a draft of the high-level features prior to the next branch being cut.

[spiffxp]

Many of the features repo issues were less than helpful for determining what the feature actually was, and what had actually been done. if we're going to put in these massive checklists, we need to actually use them, or make them small enough that they don't scare people away

Some people linked to kubernetes.github.io PR's, others linked to the final (but not actually deplpoyed) site; this generated a lot of manual legwork for me. I ultimately manually converted everything to point to the docs staging site @devin-donnelly kindly setup. It inspired confidence that yes all the docs had actually landed, and it made it easier to regex/replace to the real site.