Skip to content
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

Add release-it #33

Merged
merged 4 commits into from
Oct 2, 2023
Merged
Show file tree
Hide file tree
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
3 changes: 1 addition & 2 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@
# Changelog

# 1.1.0 (2023-09-22)

Expand All @@ -10,4 +9,4 @@

# 1.0.0 (2023-07-18)

Initial release.
Initial release.
78 changes: 78 additions & 0 deletions RELEASE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
# Release Process

Updating the Changelog and the Cargo.toml version are mostly automated using [release-it](https://github.com/release-it/release-it/) and [lerna-changelog](https://github.com/lerna/lerna-changelog/).

The deployment to npm is **automatic** and will happen when you push a tag to GitHub.

## Preparation

Since the majority of the actual release process is automated, the primary
remaining task prior to releasing is confirming that all pull requests that
have been merged since the last release have been labeled with the appropriate
`lerna-changelog` labels and the titles have been updated to ensure they
represent something that would make sense to our users. Some great information
on why this is important can be found at
[keepachangelog.com](https://keepachangelog.com/en/1.0.0/), but the overall
guiding principle here is that changelogs are for humans, not machines.

When reviewing merged PR's the labels to be used are:

* breaking - Used when the PR is considered a breaking change.
* enhancement - Used when the PR adds a new feature or enhancement.
* bug - Used when the PR fixes a bug included in a previous release.
* documentation - Used when the PR adds or updates documentation.
* internal - Used for internal changes that still require a mention in the
changelog/release notes.

## Prepare the changelog

Once the prep work is completed, the actual release is straight forward:

* Make sure that you are on a branch other than `main`. The changelog and version bump should be done as a PR, reviewed, and merged before the tag is created and the release is pushed to npm.

* ensure that you have installed your projects dependencies:

```sh
npm install
```

* ensure that you have obtained a
[GitHub personal access token][generate-token] with the `repo` scope (no
other permissions are needed). Make sure the token is available as the
`GITHUB_AUTH` environment variable.

For instance:

```bash
export GITHUB_AUTH=abc123def456
```

[generate-token]: https://github.com/settings/tokens/new?scopes=repo&description=GITHUB_AUTH+env+variable

* Update the changelog and bump the version:

```sh
npx release-it
```

[release-it](https://github.com/release-it/release-it/) manages the actual
release process. It will prompt you to to choose the version number after which
you will have the chance to hand tweak the changelog to be used.

## Tag and Release

Once your PR that updates the Changelog and bumps the version is released you need to tag that commit and push that tag to github.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need to be separate from npx release-it? or is it "better"? to do it this way for some reason?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we don't do this then only admins would be able to do a release of content-tag, rather than people who have merge permissions. This is because you can't push directly to the protected branch master

You can push tags tho

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

legit, thanks!


```sh
git checkout main
git pull
git tag v[version-number]
```

remember to replace `[version-number]` with the release you are doing.

then push that tag:

```sh
git push --tags
```
Loading