Skip to content

Latest commit

 

History

History
73 lines (54 loc) · 3.62 KB

PUBLISHING.md

File metadata and controls

73 lines (54 loc) · 3.62 KB
Raw

Publishing a new version

To publish the npm package, you'll need an npm account, and you'll need to be added to the list of maintainers by one of the current RoverUI maintainers.

With write access

  1. Checkout a release branch of some kind: (e.g. release-2.0.4 or new-v2.1.4)
  2. Following semver as your version guide, use the script yarn new-version [value] to bump the version. See yarn version docs for more info
    1. For patch: yarn new-version --patch
    2. For minor: yarn new-version --minor
    3. For major: yarn new-version --major
    4. For other: yarn new-version --new-version 3.4.11
  3. Open a PR for that branch
  4. Once you have at least one PR approval from an admin and no pending requests for changes, you can merge in to master.
  5. After your pull request is merged, follow this process:
    1. git checkout master && git fetch -p && git reset --hard origin/master
    2. yarn publish
  6. Ask an admin to push your new version's tag to GitHub.

With admin access

If you're an admin, you can commit directly to master. The process is much more streamlined.

  1. Reset your master: git checkout master && git fetch -p && git reset --hard origin/master
  2. yarn version --patch (or whatever version bump you are making)
  3. yarn publish (also pushes new tag to GitHub)
  4. git push to push your master branch with the updated CHANGELOG.md generated by our publish scripts

Drafting a release

After your tag is published, you should create a GitHub release from it.

  1. Find your tag, and compare it to the previous version by tag. Here's an example.
  2. From the Releases page, draft a new release.
  3. The title should be the same as the tag name, i.e. "v3.0.0"
  4. The description should be broken out into sections matching the conventional commit types, i.e. "Breaking changes", "Features", "Fixes", etc.
  5. You should be able to copy the list of features, fixes, etc. from the changelog, assuming your deploy followed the instructions.
  6. Ideally, the commits should be human-readable and clear, but you may want to do some light editing.
  7. When you're satisfied, publish the release.

Publishing Storybook

By default, our Storybook docs are published automatically using Github Actions. If there is an issue with this release or you need to publish this manually, use the following command:

yarn storybook:deploy

Publishing a pre-release version

You should only do this if you're an admin. Instructions based loosely on Prereleases and Npm

Edit the version in package.json manually. Pre-release versions should be named in this format:

v{MAJOR}.0.0-alpha.{BUILD}

"MAJOR" is the intended major version. Each time you deploy a new alpha build, increment the "BUILD" number. For example, v4.0.0-alpha.1 is the first iteration of what will one day become v4.

Then, from the command line:

gco -b v{MAJOR}.0.0 # E.g. gco -b v5.0.0
yarn update-changelog
git add .
git commit -m "Deploying v{MAJOR}.0.0-alpha.{BUILD}" # E.g. git commit -m "Deploying v5.0.0-alpha.2"
git push
git tag v{MAJOR}.0.0-alpha.{BUILD} # E.g. git tag v5.0.0-alpha.2
git push --tags
npm publish --tag next