Pushing a new Release

Preparing a Release

Before releasing there are a few boxes to tick off.

[ ] Is there a milestone plan for the release? If so, has it been updated?
[ ] Is the changelog up to date? (Look at commit history to verify.)
- [ ] Chronological order is fine.
- [ ] Most changes should make it into the changelog, but internal cleanups and small documentation fixes do not need to be included.
[ ] Does the AUTHORS file need updating?
[ ] Spot check new lint rules for naming consistency. Rename as needed.
[ ] Test your candidate release against the Dart SDK, Flutter, and google3 by creating a PR in gerrit:
- [ ] Upload a Dart SDK Gerrit CL with DEPS pointing to the main branch's HEAD commit.
- [ ] Run the flutter-analyze and flutter-engine-linux. These trybots will highlight code in various Flutter repositories, and internal to Google, which needs to be cleaned up before the linter release can land in the Dart SDK. TODO(srawlins): Document how to run a global presubmit for Google internal.

First, make sure the build is GREEN.

All clear? Then:

Update pubspec.yaml with a version bump and CHANGELOG.md accordingly.
Update Dart SDK's DEPS.
Publish to pub.dev (dart pub lish); heed all warnings that are not test data related!
Tag a release branch.

You're done!

Documentation on https://dart-lang.github.io/linter/ is located on the gh-pages branch and automatically updated as changes are made to the main branch.

To update the dart.dev linter rules documentation, you need to manually update the file its generated from:

Download the automatically generated rules.json file.
Rename the downloaded file to linter_rules.json.
Clone and/or open the site-www repository, creating a new branch for your changes.
Replace the old linter_rules.json with the newly downloaded version and commit your changes.
Submit your changes in a pull request with an overview of what has changed, such as what version of the linter these changes are tied to.