-
Notifications
You must be signed in to change notification settings - Fork 70
docs: Release Guidelines #306
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,62 @@ | ||
# Module Release Guidelines | ||
|
||
## Create a Proposal Issue | ||
|
||
To prepare for a new release, create a [new issue](https://github.com/cloudevents/sdk-javascript/issues/new?assignees=&labels=&template=feature-request.md&title=) where the title of the issue cleary reflects the version to be released. | ||
|
||
For example: "Proposal for 3.2.0 release", or something similar. If you are not sure which version is the next version to be released, you can run `npm run release -- --dry-run` to find out what the next version will be. | ||
|
||
The body of the issue should be the commits that will be part of the release. This can be easily accomplished by running a git log command with a defined **range**. This range should start at the most recent version tag and end at the latest commit in the master branch. | ||
|
||
For example: | ||
|
||
``` | ||
git log v3.0.1..upstream/master --oneline | ||
``` | ||
|
||
This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/master branch. | ||
|
||
This output should be pasted into the issue as normal text. This will allow Github to magically turn all commit hashes and PR/Issues numbers to links. | ||
|
||
### 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. | ||
|
||
## Create and Publish the release | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we can use a release bot instead of scripts, that may make the process easier and less error prone. |
||
|
||
Creating the release is as simple as running the release script: | ||
|
||
``` | ||
npm run release | ||
``` | ||
|
||
This will update the CHANGELOG.md and create a new tag based on the version. This can then be pushed upstream by doing: | ||
|
||
``` | ||
git push upstream master --follow-tags | ||
``` | ||
|
||
### Create the release on GitHub | ||
|
||
Once the release tag has been created and pushed up to Github, we should draft a new release using the Github UI, which is [located here](https://github.com/cloudevents/sdk-javascript/releases/new) | ||
|
||
* Tag Version should be the tag that was just created | ||
* The release title should be something like "VERSION Release" | ||
* And the Changelog entries for the current release should be copied/pasted into the comments | ||
|
||
|
||
### Publish to npm | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what about 2FA on npm, Not sure i really want to store a token anywhere There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For publishing with bots, I don't believe many packages enable 2FA for publishing (different than login). I think there are blogposts about this. |
||
|
||
Once the new version has been created, we need to push it to npm. Assuming you have all the rights to do so, just run: | ||
|
||
``` | ||
npm publish | ||
``` | ||
|
||
## Close the Issue | ||
|
||
Once the release has been completed, the issue can be closed. |
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.
I'm fine not having this step so long as all commits are approved.