In `14.2.0`, we learned that we can't bump peer deps / `latest-versions.ts` in a release PR, because the released NPM artifact is actually built *before* an opportunity to edit the PR appears. We need to do a separate before the CLI release to make this change.
See: https://angular-team.slack.com/archives/C46U16D4Z/p1661482133013029
Add the caretaker configuration to set up being able to run both the carataker
check and the handoff commands.
The caretaker handoff command will operate using the angular-cli-caretaker group
which has already been seeded with the current information.
Stephen and Igor are no longer the leads for DevRel and Angular respectively. Updated to use generic language so this doesn't fall out of date as easily.
Also turns two unrelated file references into links because it's been bugging me for ages but I was never willing to go out of my way for a separate commit or PR, and including it into another PR is kinda mixing concerns, but also who cares, so I'm just gonna do it now and hope no one notices, rant over.
This allows CLI releases to generally be done in parallel with framework and save a lot of time. Major and minor version bumps do require waiting for FW however and that is unchanged.
In v13.1, we forgot to increment this value and caused an error for early adopters of `13.1.0`. CI should catch this mistake now, and these docs will serve as a reminder to bump the value before release.
When transitioning from prerelease to stable, several SemVer ranges for packages referenced in the `package.json` files need to be adjusted so that the unsupported prerelease versions are not mentioned in the final stable release.
This will hopefully make things a little more clear and reduce the possibility that devs put the same number in both places when they actually reflect completely different values.
The process has changed and post-release bumps are no longer necessary.
Also updated the doc to include a section on changing shifts with the caveat that you must be logged in to the `@angular.io` account to have edit access to the calendar.
Now that `@angular-devkit/build-angular` is promoted to stable
(https://github.com/angular/angular-cli/pull/20528), it will
always have the same version as `@schematics/angular`.
With this change, there is no need to manually update `DevkitBuildAngular`
field in `latest-versions.ts` anymore.
This more clearly specifies that version bumps should have a PR which is assigned to the next caretaker. It also specifies that the caretaker should include these PRs in the hand-off to the next caretaker. If anyone who notices these links missing, they should escalate to the caretaker just to make sure this step is not forgotten. This should make it less likely for a caretaker for forget to do the post-release version bump.
Currently, the version of a release is determined by the git tag.
This PR changes release script to determine the release version from the
`version` property in the root `package.json`.
Release docs have also been updated.
In today's release, running `yarn` modified the `yarn.lock` file, which is not desireable for releases which should be as close to CI as possible. This updates the docs to freeze the lockfile (similar to `npm ci`) to avoid changing dependency verisons mid-release.
Today when releasing v9 and v10, I found two extra files in Git (`.husky/` and `.ng-dev.log`). These are a part of the toolchain in later versions, but not known ignored in older versions. Using `git commit -a` would have included both of those files in the release commit which would not be desirable. Instead, the solution for releases is to add the specific files that are modified to remove this possibility.
During the release today my eyes completely skipped over the new requirement to update `package.json`. Changed this to a list to give more visual weight and guide readers eyes to both places that need to be modified.
In the latest release, I was not able to build even after running `yarn` to refresh dependencies. Eventually, we tracked
the issue down to `rm -rf node_modules/`. There may be some instances where this can be necessary to ensure clean
builds.
This changes from using lightweight tags to annotated tags. The later includes author, time, and message information that is lacking from the former. It is also included in Git's `--follow-tags` option. This should allow us to push tags alongside release commits more atomically and hopefully eliminate or at least reduce the possibility of a race condition arising from CI starting on the release commit before the associated tag is pushed. Such a state causes CI failures, because they take the latest version from the most recent `v*` tag.
Previously instructions for merging to patch instructed caretakers
to only merge commits which were "applicable" to patch. However,
for PRs targeting master and patch, all commits from the PR should
land in both branches.
This is a few different edits to make caretakers more aware of problems that can occur during a release.
* Added a comment to reinforce that pushing tags needs to happen with the push of the release commit. Otherwise CI can fail `npm install` because the relevant tags are not set.
* Changed to check out the publish branch rather than the tag because checking out a tag fails the subsequent `publish` command.
* Added `yarn` before the `publish` command because dependencies may be out of date and cause errors.
If no --registry argument is provided when calling to publish
use the Wombat proxy. Additionally, updates the release process
documentation to instruct usage of the Wombat proxy.
This excludes draft PRs from Caretaker search, as the Caretaker does not actually care about draft PRs.
Also took the opportunity to make the `latest-versions.ts` file a clickable link, because it is a pain to navigate to that file in GitHub's UI.
