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.
This label should be placed by the author (or last reviewer if author is not a collaborator) when the PR is complete and ready to merged. This requires the author to explicitly acknolwedge that they are done with the PR and the caretaker is free to merge it. This label brings the CLI caretaking process into alignment with the frameworks and components repos.
This includes instructions on how to cherry-pick commits into the patch branch. Since `cherry-pick` isn't that commonly used, it's useful to write this down for developers who might not be that familiar with it. It also includes fetching the commit beforehand, so users don't get "bad object" errors which can be annoying to work around.
The `-x` option is used as well to include a reference to the commit the cherry-pick came from.
I wrote down my understanding of the best ways to build/run/test/debug this repository.
A couple other random things included here:
* Removed an extraneous `debugger;` statement which I kept hitting.
* Removed the `watch` scripts which are no longer used and don't need to be supported.
* Removed `yarn test-cli-e2e`, as it alters the $PATH and can use the wrong `ng` instance.
With this change we remove the enableIvy option as now we only support generating Ivy application. Users who want to create a VE applications should follow the opt-out guide
Add developer doc to explain how contributors and developers on the team should
treat the `package.json` file now that `angular-cli` in a mixed mode of
yarn workspaces and Bazel.
This should make it easier to manage and diff. This takes 2 things into account:
1. we have either stable or experimental versions and each are kept in monorepo.
2. we dont keep hash and update only changed packages.
This commit also removed the hash to make sure this does not happen.
