RELEASE.md
There is a script - compare-master-to-stable.js - that helps with this. We just want to make sure that good commits (low risk fixes + docs fixes) got cherry-picked into stable branch and nothing interesting got merged only into stable branch.
A super-heroic power (adverb-verb phrase).
Example Commit: https://github.com/angular/angular.js/commit/7ab5098c14ee4f195dbfe2681e402fe2dfeacd78
node_modules/.bin/changez -o changes.md -v <new version> <base branch>
Usually this will be the commit containing the release notes, but it may also be in the past.
scripts/release/release.sh --git-push-dryrun=false --commit-sha=8822a4f --version-number=1.7.6 --version-name=gravity-manipulation
The SHA is of the commit to release (could be in the past).
The version number and code-name that should be released, not the next version number (e.g. to release 1.2.12 you enter 1.2.12 as release version and the code-name that was picked for 1.2.12, cauliflower-eradication).
You will need to have write access to all the AngularJS github dist repositories and publish rights for the AngularJS packages on npm.
You can do this by filtering the current milestone, selecting via checklist, and moving to the next milestone within the GH issues page.
Google CDNs are fed with data from google3 every day at 11:15am PT it takes only few minutes for the import to propagate). If we want to make our files available, we need submit our CLs before this time on the day of the release.
This is the version used to compute what version to link to in the CDN. If you update this too early then the CDN lookup fails and you end up with 'null, for the version, which breaks the docs.
The versions in the modal are updated (based on the versions available on CDN) as part of the CI deploy stage.
(You may need to explicitly trigger the CI job. e.g. re-running the last deploy job.)
Double check that angularjs.org is up to date with the new release version before sharing.
use: git log --format='%aN' v1.2.12..v1.2.13 | sort -u