|
| 1 | +# Releasing OpenCensus Node Packages (for Maintainers Only) |
| 2 | + |
| 3 | +This document explains how to publish all OC Node modules at version x.y.z. Ensure that you’re following semver when choosing a version number. |
| 4 | + |
| 5 | +## Update to latest locally |
| 6 | + |
| 7 | +Use `git fetch` and `git checkout origin/master` to ensure you’re on the latest commit. Make sure |
| 8 | +you have no unstaged changes. Ideally, also use `git clean -dfx` to remove all ignored and |
| 9 | +untracked files. |
| 10 | + |
| 11 | +## Create a new branch |
| 12 | + |
| 13 | +Create a new branch called `x.y.z-proposal` from the current commit. |
| 14 | + |
| 15 | +## Use Lerna to prepare each package for release |
| 16 | + |
| 17 | +Use `npm install` and `lerna bootstrap` to initialize all package directories. |
| 18 | +Also, use `lerna publish --skip-npm --skip-git` to bump version numbers. |
| 19 | +Ensure that the version being bumped to is `x.y.z`. This should create some unstaged changes. |
| 20 | + |
| 21 | +## Create a new commit |
| 22 | + |
| 23 | +Create a new commit with the exact title: `chore(multiple): x.y.z release proposal`. |
| 24 | + |
| 25 | +## Use the Changelog to create a GitHub Release |
| 26 | + |
| 27 | +On [GitHub Releases](https://github.com/census-instrumentation/opencensus-node/releases), |
| 28 | +follow the example set by recent releases to populate a summary of changes, as well as a list of |
| 29 | +commits that were applied since the last release. `git log --oneline --no-decorate` is a good way |
| 30 | +to get that list of commits. Save it as a draft, don’t publish it. Don’t forget the tag -- call |
| 31 | +it `vx.y.z` and leave it pointing at `master` for now (this can be changed as long as the GitHub |
| 32 | +release isn’t published). |
| 33 | + |
| 34 | +## Create a new PR |
| 35 | + |
| 36 | +Push the branch to GitHub and create a new PR with that exact name. The commit body should just |
| 37 | +be a link to the *draft* notes. Someone who can access draft notes should approve it, looking |
| 38 | +in particular for test passing, and whether the draft notes are satisfactory. |
| 39 | + |
| 40 | +## Merge and pull |
| 41 | + |
| 42 | +Merge the PR, and pull the changes locally (using the commands in the first step). Ensure that |
| 43 | +`chore(multiple): x.y.z release proposal` is the most recent commit. |
| 44 | + |
| 45 | +## Publish all packages |
| 46 | + |
| 47 | +Go into each directory and use `npm publish` to publish the package. You can use the following |
| 48 | +script to automate this. |
| 49 | + |
| 50 | +```bash |
| 51 | +#!/bin/bash |
| 52 | + |
| 53 | +for dir in $(ls packages); do |
| 54 | + pushd packages/$dir |
| 55 | + npm publish |
| 56 | + popd |
| 57 | +done |
| 58 | +``` |
| 59 | + |
| 60 | +Check your e-mail and make sure the number of “you’ve published this module” emails matches the number you expect. |
| 61 | + |
| 62 | +## Publish the GitHub Release |
| 63 | + |
| 64 | +Publish the GitHub release, ensuring that the tag points to the newly landed commit corresponding to release proposal `x.y.z`. |
0 commit comments