Release-Process.md

   1 # Express Release Process
   2
   3 This document contains the technical aspects of the Express release process. The
   4 intended audience is those who have been authorized by the Express Technical
   5 Committee (TC) to create, promote and sign official release builds for Express,
   6 as npm packages hosted on https://npmjs.com/package/express.
   7
   8 ## Who can make releases?
   9
  10 Release authorization is given by the Express TC. Once authorized, an individual
  11 must have the following access permissions:
  12
  13 ### 1. Github release access
  14
  15 The individual making the release will need to be a member of the
  16 expressjs/express team with Write permission level so they are able to tag the
  17 release commit and push changes to the expressjs/express repository
  18 (see Steps 4 and 5).
  19
  20 ### 2. npmjs.com release access
  21
  22 The individual making the release will need to be made an owner on the
  23 `express` package on npmjs.com so they are able to publish the release
  24 (see Step 6).
  25
  26 ## How to publish a release
  27
  28 Before publishing, the following preconditions should be met:
  29
  30 - A release proposal issue or tracking pull request (see "Proposal branch"
  31   below) will exist documenting:
  32   - the proposed changes
  33   - the type of release: patch, minor or major
  34   - the version number (according to semantic versioning - http://semver.org)
  35 - The proposed changes should be complete.
  36
  37 There are two main release flows: patch and non-patch.
  38
  39 The patch flow is for making **patch releases**. As per semantic versioning,
  40 patch releases are for simple changes, eg: typo fixes, patch dependency updates,
  41 and simple/low-risk bug fixes. Every other type of change is made via the
  42 non-patch flow.
  43
  44 ### Branch terminology
  45
  46 "Master branch"
  47
  48 - There is a branch in git used for the current major version of Express, named
  49   `master`.
  50 - This branch contains the completed commits for the next patch release of the
  51   current major version.
  52 - Releases for the current major version are published from this branch.
  53
  54 "Version branch"
  55
  56 - For any given major version of Express (current, previous or next) there is
  57   a branch in git for that release named `<major-version>.x` (eg: `4.x`).
  58 - This branch points to the commit of the latest tag for the given major version.
  59
  60 "Release branch"
  61
  62 - For any given major version of Express, there is a branch used for publishing
  63   releases.
  64 - For the current major version of Express, the release branch is the
  65   "Master branch" named `master`.
  66 - For all other major versions of Express, the release branch is the
  67   "Version branch" named `<major-version>.x`.
  68
  69 "Proposal branch"
  70
  71 - A branch in git representing a proposed new release of Express. This can be a
  72   minor or major release, named `<major-version>.0` for a major release,
  73   `<major-version>.<minor-version>` for a minor release.
  74 - A tracking pull request should exist to document the proposed release,
  75   targeted at the appropriate release branch. Prior to opening the tracking
  76   pull request the content of the release may have be discussed in an issue.
  77 - This branch contains the commits accepted so far that implement the proposal
  78   in the tracking pull request.
  79
  80 ### Pre-release Versions
  81
  82 Alpha and Beta releases are made from a proposal branch. The version number should be
  83 incremented to the next minor version with a `-beta` or `-alpha` suffix.
  84 For example, if the next beta release is `5.0.1`, the beta release would be `5.0.1-beta.0`.
  85 The pre-releases are unstable and not suitable for production use.
  86
  87 ### Patch flow
  88
  89 In the patch flow, simple changes are committed to the release branch which
  90 acts as an ever-present branch for the next patch release of the associated
  91 major version of Express.
  92
  93 The release branch is usually kept in a state where it is ready to release.
  94 Releases are made when sufficient time or change has been made to warrant it.
  95 This is usually proposed and decided using a github issue.
  96
  97 ### Non-patch flow
  98
  99 In the non-patch flow, changes are committed to a temporary proposal branch
 100 created specifically for that release proposal. The branch is based on the
 101 most recent release of the major version of Express that the release targets.
 102
 103 Releases are made when all the changes on a proposal branch are complete and
 104 approved. This is done by merging the proposal branch into the release branch
 105 (using a fast-forward merge), tagging it with the new version number and
 106 publishing the release package to npmjs.com.
 107
 108 ### Flow
 109
 110 Below is a detailed description of the steps to publish a release.
 111
 112 #### Step 1. Check the release is ready to publish
 113
 114 Check any relevant information to ensure the release is ready, eg: any
 115 milestone, label, issue or tracking pull request for the release. The release
 116 is ready when all proposed code, tests and documentation updates are complete
 117 (either merged, closed or re-targeted to another release).
 118
 119 #### Step 2. (Non-patch flow only) Merge the proposal branch into the release branch
 120
 121 In the patch flow: skip this step.
 122
 123 In the non-patch flow:
 124 ```sh
 125 $ git checkout <release-branch>
 126 $ git merge --ff-only <proposal-branch>
 127 ```
 128
 129 <release-branch> - see "Release branch" of "Branches" above.
 130 <proposal-branch> - see "Proposal branch" of "Non-patch flow" above.
 131
 132 **NOTE:** You may need to rebase the proposal branch to allow a fast-forward
 133           merge. Using a fast-forward merge keeps the history clean as it does
 134           not introduce merge commits.
 135
 136 ### Step 3. Update the History.md and package.json to the new version number
 137
 138 The changes so far for the release should already be documented under the
 139 "unreleased" section at the top of the History.md file, as per the usual
 140 development practice. Change "unreleased" to the new release version / date.
 141 Example diff fragment:
 142
 143 ```diff
 144 -unreleased
 145 -==========
 146 +4.13.3 / 2015-08-02
 147 +===================
 148 ```
 149
 150 The version property in the package.json should already contain the version of
 151 the previous release. Change it to the new release version.
 152
 153 Commit these changes together under a single commit with the message set to
 154 the new release version (eg: `4.13.3`):
 155
 156 ```sh
 157 $ git checkout <release-branch>
 158 <..edit files..>
 159 $ git add History.md package.json
 160 $ git commit -m '<version-number>'
 161 ```
 162
 163 ### Step 4. Identify and tag the release commit with the new release version
 164
 165 Create a lightweight tag (rather than an annotated tag) named after the new
 166 release version (eg: `4.13.3`).
 167
 168 ```sh
 169 $ git tag <version-number>
 170 ```
 171
 172 ### Step 5. Push the release branch changes and tag to github
 173
 174 The branch and tag should be pushed directly to the main repository
 175 (https://github.com/expressjs/express).
 176
 177 ```sh
 178 $ git push origin <release-branch>
 179 $ git push origin <version-number>
 180 ```
 181
 182 ### Step 6. Publish to npmjs.com
 183
 184 Ensure your local working copy is completely clean (no extra or changed files).
 185 You can use `git status` for this purpose.
 186
 187 ```sh
 188 $ npm login <npm-username>
 189 $ npm publish
 190 ```
 191
 192 **NOTE:** The version number to publish will be picked up automatically from
 193           package.json.
 194
 195 ### Step 7. Update documentation website
 196
 197 The documentation website https://expressjs.com/ documents the current release version in various places.  For a new release:
 198 1. Change the value of `current_version` in https://github.com/expressjs/expressjs.com/blob/gh-pages/_data/express.yml to match the latest version number.
 199 2. Add a new section to the change log.  For example, for a 4.x release, https://github.com/expressjs/expressjs.com/blob/gh-pages/en/changelog/4x.md,