Skip to content

chore: update the release documentation #476

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

Merged
merged 1 commit into from
Feb 16, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 9 additions & 49 deletions RELEASE_GUIDELINES.md
Original file line number Diff line number Diff line change
@@ -1,53 +1,17 @@
# Module Release Guidelines

## Create a Proposal Issue
## `release-please`

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.
This project uses [`release-please-action`](https://github.com/google-github-actions/release-please-action)
to manage CHANGELOG.md and automate our releases. It does so by parsing the git history, looking for
[Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) messages, and creating release PRs.

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 main branch.

For example:

```
git log v3.0.1..upstream/main --oneline
```

This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/main 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

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 main --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
For example: https://github.com/cloudevents/sdk-javascript/pull/475

Each time a commit lands on `main`, the workflow updates the pull request to include the commit message
in CHANGELOG.md, and bump the version in package.json. When you are ready to create a new release, simply
land the pull request. This will result in a release commit, updating CHANGELOG.md and package.json, a version
tag is created on that commit SHA, and a release is drafted in github.com.

### Publish to npm

Expand All @@ -56,7 +20,3 @@ Once the new version has been created, we need to push it to npm. Assuming you
```
npm publish
```

## Close the Issue

Once the release has been completed, the issue can be closed.