-
Notifications
You must be signed in to change notification settings - Fork 47
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.
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
Release procedure #372
Release procedure #372
Conversation
Headers take care of this and this way we don't need to renumber if we change the process.
There was a problem hiding this 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
|
||
* 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
RELEASE.md
Outdated
|
||
## Documents | ||
|
||
* Check that the version (e.g. `1.10`) in `cf-conventions.adoc` is correct. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
* `conformance.pdf` | ||
|
||
## Set new draft version | ||
* Set the new *next* version in `cf-conventions.adoc`, and change the |
There was a problem hiding this comment.
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.
This should be merged together with cf-convention/cf-convention.github.io#231
Hopefully I've captured all of the versioning and actions stuff in 4c9e120 |
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 ... |
Issue345+371
Superseded by #498 |
Superseded by #498
See issue #371 for discussion of these changes.Release checklist
cf-conventions.adoc
?cf-conventions.adoc
up to date? Versioning inspired by SemVer.history.adoc
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.