docs: Release Guidelines #306
Conversation
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
No it doesn't. Good catch - I guess a step in the process should be to amend that commit
The docs are automatically published on release using a github workflow
Yes, probably so. GitHub considers a new tag a release, for the purposes of workflows, but I try to copy the generated section of CHANGELOG.md and paste it into the release markdown here We may also want to add a step to the release process to actually create a branch for the release version, in addition to a tag. This has been discussed before and rejected, but it would make possible @grant's suggestion below.
That's a decent suggestion, but I don't think we should do that for every push to |
|
Yup, not sure exactly how the bot would work with the branching, but I definitely recommend setting up GitHub actions for automatic release PR creation and automatic publishing when the PR is merged by a human. |
RELEASE_GUIDELINES.md
Outdated
|
|
||
| Before a release can be finalized, other maintainers should give a +1 or a thumbs up or some other identifying mark that they are good with the changes. | ||
|
|
||
| // TODO: should we wait a specified time after the +1's before we create |
There was a problem hiding this comment.
I don't think this is necessary. All PRs should only land if a maintainer approved it.
|
|
||
| ### Get Consensus | ||
|
|
||
| Before a release can be finalized, other maintainers should give a +1 or a thumbs up or some other identifying mark that they are good with the changes. |
There was a problem hiding this comment.
I'm fine not having this step so long as all commits are approved.
|
|
||
| Once consensus has been reached on the proposal it is time to create the release and publish it to npm. | ||
|
|
||
| ### Create the Release |
There was a problem hiding this comment.
If we can use a release bot instead of scripts, that may make the process easier and less error prone.
| git push upstream master --follow-tags | ||
| ``` | ||
|
|
||
| ### Publish to npm |
There was a problem hiding this comment.
A release bot would sent a PR that would automatically publish when the PR is merged by a human.
There was a problem hiding this comment.
what about 2FA on npm, Not sure i really want to store a token anywhere
There was a problem hiding this comment.
For publishing with bots, I don't believe many packages enable 2FA for publishing (different than login). I think there are blogposts about this.
Similar to @lance 's thought, i'm not a big fan of having a release on every single push to master. We don't really need a new release everytime a new snyk PR is merged or a typo on a Readme. I think we should revisit the "create a new branch for a release" workflow and see how github actions fits into that. I'm also reminded of this tweet i saw the other day:
The main reason for the document, is that we have a pending release, #300 , that we should probably get out this week, and we didn't have any document about the process. So if this works for our current process, then we can iterate on it later |
Definitely agree with this. Let's get through this doc using the existing processes and open an issue around release automation. |
|
addressing the signoff of the release commit in this PR #307 |
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
This is the start of a release guidelines for maintainers.
I think i have everything here. There is one TODO, asking if we should have a specified time after the last "+1" from other maintainers.
Outstanding questions:
Description