Skip to content

Releasing

Jump to bottom
Daniel Imms edited this page Jun 26, 2019 · 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
  7. Fill in compatible versions of addons in the release notes, see the following section on whether releases need to be done

Publishing the release

Now update the xterm version number. If there were any code changes to an addon made during this milestone, a stable release of the addon should be done. To do this bump the major or minor version of the addon's package.json.

Use this branch to submit a PR and make sure CI passes. Once merged Azure Pipelines should release the new versions of the library and the addons in the publish step of the master branch build.

Now publish the GitHub release, by naming the release in the x.y.z format it should also create the version tag when the release is published.

Website

For every major and minor version the website should also be updated. To do this fork and clone xtermjs/xtermjs.org then update the docs as described in the readme and do a PR with the changes. Merging the PR will deploy the website.

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>

Update the version in package.json, save and create a new commit for the version:

git add .
git commit -m "v3.9.0"

Push to the remote:

git push --set-upstream origin release/3.9

Once the branch is ready, queue a manual build setting "Branch" to the branch name (eg. release/3.9). This should release automatically if the release branch is named correctly.

Now publish the GitHub release like in normal releases, by naming the release in the x.y.z format it should also create the version tag when the release is published.

Clone this wiki locally