Skip to content

Releasing

Daniel Imms edited this page Dec 11, 2018 · 28 revisions

Code freeze

xterm.js is released approximately once a month. As the release date approaches say around 3-5 days before the scheduled date the code is frozen, this means all PRs that are non-trivial or important bug fixes are deferred until after the release is done. This helps minimize the risk of bugs coming in at last second that could cause the need for a patch release.

Release notes

As the date approaches the release notes need to be created. Here are the steps for this:

  1. Go to the releases page and create a new draft.

  2. Copy the headers from a recent release.

  3. Open the pull requests page and make sure that all recent pull requests have correct milestones attached to them as sometimes PRs get merged in without a milestone. While doing this, also check the referenced issues to make sure they are closed off and assigned to the milestone too.

  4. Open the pull requests page again and assign the release's milestone.

  5. Go through each of the PRs and make a line item under the heading that makes the most sense, use this format:

    • (#issue) via @author
  6. Go through the release and merge similar issues where it makes sense. Typically do this for internal improvements as they're not as important for end users, or for PRs which were done as a series, for example:

    • (#issue1, #issue2) via @author1, @author2

Publishing the release

First step is to update the version number through the GitHub UI, this will give a signed commit.

Then publish the release to npm:

# Pull in version change commit
git pull

# Build to dist/
BUILD_DIR=dist npm run build

# Publish the release
npm publish

Now publish the GitHub release, you can let GitHub create the version tag.

Verifying after publish

After publishing the build can be verified easily using the electron example in node-pty. Just clone that, update the dependency and run the project.

Patch releases

In order to do a patch release you will need to checkout the released tag that you're releasing from:

git checkout 3.9.0

Then branch that off:

git checkout -b release/3.9

Cherry pick changes that have already landed in master to that branch:

git cherry-pick <commit sha>

Then push the branch and release as normal. Once the release has been tagged the branch can be deleted safely.