[lholmquist]

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:

• does the current release script also sign and adds the "signed-off by" thing
• Should we mention something on publishing docs here
• Should we add that we should create a "release" on github

Description

• Fixes Issue Release Procedure Document #304

[grant]

Can we use a GitHub action for automatic releases on push to master?

[lance]

@lholmquist

does the current release script also sign and adds the "signed-off by" thing

No it doesn't. Good catch - I guess a step in the process should be to amend that commit

Should we mention something on publishing docs here

The docs are automatically published on release using a github workflow

Should we add that we should create a "release" on github

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.

@grant

Can we use a GitHub action for automatic releases on push to master?

That's a decent suggestion, but I don't think we should do that for every push to master since that would mean a release for every PR that lands. If we create a branch for each release, then we could have a workflow handle the actual releases, and our release process would be simply pushing the new branch. The workflow would detect the branch and then do the steps that are outlined above. But I'm not sure I love this idea.

[lance]

LGTM other than the signoff issue, and copying the CHANGELOG updates to the release body in GitHub

[grant]

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.

[grant]

I don't think this is necessary. All PRs should only land if a maintainer approved it.

[grant]

I'm fine not having this step so long as all commits are approved.

[grant]

If we can use a release bot instead of scripts, that may make the process easier and less error prone.

[grant]

A release bot would sent a PR that would automatically publish when the PR is merged by a human.

[lholmquist]

what about 2FA on npm, Not sure i really want to store a token anywhere

[grant]

For publishing with bots, I don't believe many packages enable 2FA for publishing (different than login). I think there are blogposts about this.

[lholmquist]

Can we use a GitHub action for automatic releases on push to master?

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:

"Never spend 6 minutes doing something by hand when you can spend 6 hours failing to automate it" :)

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

[lance]

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.

[lholmquist]

addressing the signoff of the release commit in this PR #307