Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release procedure #372

Closed
wants to merge 13 commits into from
Closed

Release procedure #372

wants to merge 13 commits into from

Conversation

davidhassell
Copy link
Contributor

@davidhassell davidhassell commented Jul 28, 2022 •
edited
Loading

Superseded by #498

See issue #371 for discussion of these changes.

Release checklist

  • [NA ] Authors updated in cf-conventions.adoc?
  • [NA] Next version in cf-conventions.adoc up to date? Versioning inspired by SemVer.
  • [NA] history.adoc up to date?
  • [NA] Conformance document up-to-date?

For maintainers

After the merge remember to delete the source branch.
Tags are set at the conclusion of the annual meeting; until then master always is a draft for the next version.

@erget
master --> main
addc374
@erget
Formatting
0cb7fcc
@erget
Remove numbering
84d8615 
Headers take care of this and this way we don't need to renumber if we change the process.
erget
erget reviewed Jul 28, 2022
View reviewed changes
Copy link
Member

@erget erget left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly good, I inserted some comments where I think the doc could be improved.

Might it make more sense to put each sentence on its own line rather than wrapping it? Makes it easier to use git blame down the road.

RELEASE.md Outdated Show resolved Hide resolved
RELEASE.md Outdated

* Tag the `main` branch with the new version (e.g. `v1.10.0`).
* Create a new "Latest release" that contains a link to the Pull
Requests that contributed to the new version. Include a link to the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sentence starting on this line looks like it might be a leftover from something.

What is the appropriate GitHub Milestone?

RELEASE.md Outdated
* Set the new *next* version in `conformance.adoc`.

## Add the release documents
* Move to the cf-convention.github.io repository
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hyperlink?

RELEASE.md Outdated
## Announce the release

* Wait until all changes are visible via the web site, and then
announce the release on `cf-convention/discuss/issues`. There may
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hyperlink to https://github.com/cf-convention/discuss/issues/new/ ? For quality of life.

ethanrd
ethanrd reviewed Jul 28, 2022
View reviewed changes
RELEASE.md Outdated

## Documents

* Check that the version (e.g. `1.10`) in `cf-conventions.adoc` is correct.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be handled with changes to version.adoc (uncomment the "final" attribute) now that PR #344 / issue #343 are merged/closed?

Same below with release date and version in cf-conventions.adoc and conformance.adoc.
(On second look, I don't think the the "final" attribute handles the date.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ha! I'd forgotten about that. This will make things much easier. Am I right in think that all we need to do is change // :final: to :final: in version.adoc, then? and change it back after the artefacts have been created?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not even that should be necessary. The way this (supposedly) works is that in the workflow a command line switch is added iff the build is due to a release, which automatically produces the final version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @zklaus and @ethanrd - sounds good, but how do does the build now that it is a release? The current procedure simply get the results of the most recent run of the guhub actions. What am I missing? Thanks,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @davidhassell - I believe a new release should cause the workflow that @zklaus mentions above to build with the final attribute/tag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Ethan, that makes sense to me, now. I'll update the procedure with that in mind.

RELEASE.md Outdated Show resolved Hide resolved
RELEASE.md Outdated
* `conformance.pdf`

## Set new draft version
* Set the new *next* version in `cf-conventions.adoc`, and change the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I think this is now handled in version.adoc. Also, it looks like "[ |-]draft" is added to the version string if the "final" attribute is not defined but the date is not added if "final" is defined. I can't remember if there was a reason the release date wasn't handled by this mechanism.

@erget erget mentioned this pull request Aug 12, 2022
Closed
erget added a commit that referenced this pull request Aug 15, 2022
@erget
Request moderator note discussion contributions
aeeabfc 
Closes cf-convention/cf-convention.github.io#230 together with #372
@erget erget mentioned this pull request Aug 15, 2022
Closed
4 tasks
@erget erget mentioned this pull request Aug 15, 2022
Closed
@davidhassell
Copy link
Contributor Author

Hopefully I've captured all of the versioning and actions stuff in 4c9e120

@davidhassell
Copy link
Contributor Author

Ethan and I thought that we should now try and use this procedure on the release of CF-1.10 (in a couple of weeks, or so), fixing any problems with the checklist as we go. Then the "proven" release procedure can be merged, ready for CF-1.11 ...

@erget erget linked an issue Aug 23, 2022 that may be closed by this pull request
Add a RELEASE.md describing how to release a new version of CF #371
Open
@erget erget mentioned this pull request Aug 23, 2022
Open
@erget erget mentioned this pull request Aug 23, 2022
Closed
@davidhassell davidhassell mentioned this pull request Dec 5, 2023
Open
4 tasks
@davidhassell
Copy link
Contributor Author

Superseded by #498

@davidhassell davidhassell removed a link to an issue Dec 5, 2023
Add a RELEASE.md describing how to release a new version of CF #371
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ethanrd ethanrd ethanrd left review comments

@zklaus zklaus zklaus left review comments

@erget erget erget left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@davidhassell @ethanrd @zklaus @erget @JonathanGregory