Skip to content

Releasing

Jump to bottom
Daniel Imms edited this page May 9, 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

Publishing the release

First step is to update the version number and submit a PR. Once merged Azure Pipelines should release the new version in the publish step.

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

Every major/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>

Then push the branch and release as normal. Once the release has been tagged (make sure to change the branch on the GH releases page) the branch can be deleted safely.

Clone this wiki locally