Skip to content

Latest commit

 

History

History
178 lines (135 loc) · 7.5 KB

release.md

File metadata and controls

178 lines (135 loc) · 7.5 KB

Setting Up Local Repository

  1. Clone the Angular-CLI repo. A local copy works just fine.
  2. Create an upstream remote:
$ git remote add upstream https://github.com/angular/angular-cli.git

Caretaker

The caretaker should triage issues, merge PR, and sheppard the release.

Caretaker rotation can be found here and individual shifts can be modified as necessary to accommodate caretaker's schedules. This automatically syncs to a Google Calendar here. Click the "+" button in the bottom right to add it to your calendar to see shifts alongside the rest of your schedule.

The primary caretaker is responsible for both merging PRs and performing the weekly release. The secondary caretaker does not have any direct responsibilities, but they may need to take over the primary's responsibilities if the primary is unavailable for an extended time (a day or more) or in the event of an emergency.

At the end of each caretaker's rotation, the primary should perform a handoff in which they provide information to the next caretaker about the current state of the repository and update the access group to now include the next caretakers. To perform this update to the access group, the caretaker can run:

$ pnpm ng-dev caretaker handoff

Merging PRs

The list of PRs which are currently ready to merge (approved with passing status checks) can be found with this search. This list should be checked daily and any ready PRs should be merged. For each PR, check the target label to understand where it should be merged to. You can find which branches a specific PR will be merged into with the pnpm ng-dev pr check-target-branches <pr> command.

When ready to merge a PR, run the following command:

pnpm ng-dev pr merge <pr>

Maintaining LTS branches

Releases that are under Long Term Support (LTS) are listed on angular.dev.

Since there could be more than one LTS branch at any one time, PR authors who want to merge commits into LTS branches must open a pull request against the specific base branch they'd like to target.

In general, cherry picks for LTS should only be done if it meets one of the criteria below:

  1. It addresses a critical security vulnerability.
  2. It fixes a breaking change in the external environment. For example, this could happen if one of the dependencies is deleted from NPM.
  3. It fixes a legitimate failure on CI for a particular LTS branch.

Release

Releasing is performed using Angular's unified release tooling. Each week, two releases are expected, latest and next on npm.

DURING a minor OR major CLI release:

Once FW releases the actual minor/major release (for example: 13.0.0 or 13.1.0), update dependencies with the following:

  1. Update constants.bzl so @angular/core and ng-packagr are using the release version (drop -next.0).

Merge the above change in a separate PR which lands after FW releases (or else CI will fail) but before the CLI release PR. Releases are built before the PR is sent for review, so any changes after that point won't be included in the release.

AFTER a minor OR major CLI release:

constants.bzl also needs to be updated to use -next.0 after a major or minor release. However this needs to happen after FW publishes the initial -next.0 release, which will happen 1 week after the major or minor release.

Releasing the CLI

Typical patch and next releases do not require FW to release in advance, as CLI does not pin the FW dependency.

After confirming that the above steps have been done or are not necessary, run the following and navigate the prompts:

pnpm ng-dev release publish

Releases should be done in "reverse semver order", meaning they should follow:

Oldest LTS -> Newest LTS -> Patch -> RC -> Next

This can skip any versions which don't need releases, so most weeks are just "Patch -> Next".

Releasing a new package

Wombat has some special access requirements which need to be configured to publish a new NPM package.

See this Wombat doc and this postmortem for more info.

Angular is not an organization on NPM, therefore each package is published independently and Wombat access needs to be managed individually. This also means we can't rely on Wombat already having access to a new package.

In order to configure a brand new NPM package, it first needs to be published manually so we can add Wombat access to it. Note that this step can and should be done prior to weekly releases. The sooner this can be done, the less likely it will block the next weekly release.

  1. Check out the main branch, which should always have a -next version.
    • This avoids having the initial publish actually be used in production.
  2. Trigger a release build locally. 
    nvm install
pnpm install --frozen-lockfile
pnpm ng-dev release build
  3. Log in to NPM as angular. 
    npm login
  4. Publish the release. 
    (cd dist/releases/my-scope/my-pkg/ && npm publish --access public)
  5. Add Wombat to the package. 
    npm owner add google-wombot @my-scope/my-pkg
  6. Don't forget to logout. 
    npm logout
  7. File a bug like b/336626936 to ask Wombat maintainers to accept the invite for the new package.

Once Wombat accepts the invite, regular automated releases should work as expected.

Updating Browser Support

Angular's browser support is defined by a Baseline "widely available" date. Before a new major version is released, this should be updated to approximately the current date.

A few weeks before a major (around feature freeze):

  1. Update BASELINE_DATE in /constants.bzl to the end of the most recent month.
    • For example, if it is currently May 12th, set baselineThreshold to April 30th.
    • Picking a date at the end of a month makes it easier to cross-reference Angular's support with other tools (like MDN) which state Baseline support using month specificity.
    • You can view the generated browserlist configuration with: 
      bazel build //packages/angular/build:angular_browserslist
cat dist/bin/packages/angular/build/.browserslistrc
    • Commit and merge the change, no other alterations or automation is necessary in the CLI repo.
  2. Update /.browserslistrc in the ng-packagr repo.
    • Use the generated configuration from above.
  3. Update angular.dev documentation to specify the date used and link to browsersl.ist with the generated configuration.