gbm CLI checklist includes "Before the Release" steps

[dcalhoun]

Generally, we have a task resembling something the following, but it is not currently present in the gbm CLI.

Visit all open gutenberg-mobile PRs that are assigned to 1.92.0 milestone and leave a comment with a message similar to the following:

Hey [author]. We will cut the 1.92.0 release on [date]. I plan to circle back and bump this PR to the next milestone then, but please let me know if you’d rather us work to include this PR in 1.92.0. Thanks!

[jhnstn]

The "Before the Release (Tuesday)" section should always appear for scheduled releases (X.XX.0).
Right now it is hidden for patch releases ( X.XX.1 for example )

One guiding idea in updating the checklist is to remove unnecessary steps. In this case there should be no need to visit PRs assigned to a milestone if that milestone doesn't exist.

It does look like we sometimes create milestones for patch releases. Wondering if we should formalize that as being or not being a requirement? I'm fine either way but if we go with the former than yes, the checklist generator should always include this section.

On the other hand I'm not sure the intent of the how this step is worded make sense for a patch. I've found this step as a way to help the wrangler point out pending work that they otherwise might not know about. Also the action of pinging someone reminds them that we are nearing a release.

Perhaps for a patch release, this step should:

1. Have the wrangler check for a patch milestone.
2. If one exists, verify that the all the milestone PRs are merged.

I would think we wouldn't want to move forward with a patch release if there is outstanding work targeting the patch milestone.

[dcalhoun]

IIRC my intention with this issue was reporting that the "Before the Release" section was absent after I generated as scheduled release checklist using the gbm CLI. So, it was not commentary on whether unscheduled releases should have milestones or the "Before the Release" section.

I agree unscheduled releases are inconsistent as to whether a GitHub milestone is utilized.

[jhnstn]

I think this another case of calling the script with out the 0 patch value – see #137 (comment)

[jhnstn]

Fixed in #146