Add a RELEASE.md describing how to release a new version of CF

[davidhassell]

After CF-1.9 was released the release procedure was written up, but never made to a PR. Here it is now, in time for CF-1.10.

[erget]

Hi @davidhassell I made some changes and also inserted some comments - have a look and see what you think :)

[erget]

Additional changes concerning keeping contributor list up to date agreed in cf-convention/cf-convention.github.io#230. These were introduced in 0b20db2 and bf274bc

[JonathanGregory]

In CONTRIBUTING.md we have

When an issue and accompanying pull request concludes with an agreed change to the conventions, the pull request is merged into the master branch according to the Rules for CF Convention Changes.
The pull request is merged by a member of the Governance Panel or the CF Conventions and Standard Names Committee. The person who merges the pull request also closes the issue.

Following #345 agreed last week, we should add here:

The issue should be given the change agreed label, and the pull request should be given the next release number as a milestone.

I suggest that this sentence or something like it should be inserted between the other two.

Jonathan

[erget]

@JonathanGregory that looks fine for me, I would approve that.

BTW your note reminds me that we have yet to align the terminology everywhere of using "main" rather than "master" as branch name; I've submitted #376 to correct this in CONTRIBUTING.md, somehow I missed that when implementing cf-convention/discuss#125. Would appreciate if somebody takes a look at those minor but important changes.

[JonathanGregory]

I have inserted a list of tasks, because I thought that made it clearer. Please see this PR.

[erget]

Now this issue has produced 3 PRs. One's already merged because it was a simple error. Are the other 2 agreed? If they are, we could merge them sequentially, or merge 1 into the other and then merge the whole shebang when that's done. Both open PRs are valuable in my view and should be merged once it's clear that they're agreed (from my perspective that could be the case now, but others may disagree).

I believe the cleanest thing would be

• Raise a PR from branch JonathanGregory:issue345+371 to davidhassell:release-procedure. That would put those changes together with those already discussed in Release procedure #372 once merged. I've done this now; @davidhassell if you're happy with those changes please merge that PR.
• Close add instructions about milestone and change agreed label, following i… #377, since those changes are now in Release procedure #372
• Review Release procedure #372 in its entirety, then merge once agreed.

Does that make sense?

[davidhassell]

Sounds good. Edit Just to be clear, "that PR" of the first action is #377 ? I see it now: davidhassell#4. More edits: now merged!

[davidhassell]

(premature send) .... also, might be good to note that we only intend to merge #372 after we've used it for 1.10, as only then do we know it works (#372 (comment))

[erget]

Sounds good.Just to be clear, "that PR" of the first action is #377 ?

Yes.

(premature send) .... also, might be good to note that we only intend to merge #372 after we've used it for 1.10, as only then do we know it works (#372 (comment))

I'd forgotten about that, absolutely right.

[larsbarring]

Hi @davidhassell I just had quick look at your new PR #498. From my outside perspective it looks good, but I guess only you and other release manages can judge. Nevertheless, here are two small observations:

• The release date, that I tried to automate in issue #457 / PR#475 didn't work out in the end (hence cf-convention.github.io/428) I am not sure whether this automation could be fixed, or if the manual step needs to be recorded in the procedure.
• The released version number, and the new draft version number, appears at quite a few places. Is this something that could be further automated ?

[JonathanGregory]

Once a release is done, we need a milestone for the next one. I have just created the 1.12 milestone in order to attribute a PR to it.

[davidhassell]

Thanks, @JonathanGregory, creating the next milestone has been added (0d77329).

[davidhassell]

Hi. Yet another PR for the release procedure: #588

This was used for the release of CF-1.12, and is the simplest and mot robust one yet - mainly due to the great effort of others to make this a nicer process - thank you :)

The procedure described in the PR is what I actually did for releasing CF-1.12, so I guess that's a proof that it works. It would be nice if someone could look through it and imagine they were doing it for themselves, to see if it makes sense!

It might be a good idea to add a fifth checkbox to the Pull Request template to ask if the release procedure document is up to date. Hopefully in that way it will evolve nicely.

David

[JonathanGregory]

Dear David

Thank you! It looks good to me. I have noted a couple of typos. Also, I have suggestions:

• Having added new contributors to the list of contributors, remove the new contributor label from the issue concerned.
• Add the change agreed label to any issue which has been incorporated in the new release, if it's not there.
• Close the issue, if it isn't already.
• Something about milestones, perhaps. It must be a preliminary step that you make sure all the accepted changes to be included have the milestone for the new release. You and I discussed this, but I don't recall what we said. Should the milestone be attached to the issue as well as the PR, for instance?

Best wishes

Jonathan