[!NOTE] There are parts of this release process that can only be completed by Googlers on the Dash team. If you are not a Googler on the Dash team, please reach out on the #hackers-devtools Discord channel before trying to create a DevTools release.

DevTools release process

A new minor version of DevTools should be released into the Dart SDK monthly. This release should be timed with the Dart / Flutter release code cutoff dates so that we can ensure it is included with the next Flutter beta (see the Dash release schedule). The minor DevTools releases must be submitted to the Dart SDK before the Beta release cutoff date. Dev or patch releases of DevTools may occur as needed between minor or major releases.

Before each minor or major DevTools release, the DevTools team will perform a bug bash for quality assurance and to prevent regressions from slipping into the release.

How to release Dart DevTools

Release into the Dart SDK master branch
Cherry-pick releases into the Dart SDK stable / beta branches

Release into the Dart SDK master branch

Configure/Refresh environment

Make sure:

Your Dart SDK is configured:
a. You have a local checkout of the Dart SDK
- (for getting started instructions, see sdk/CONTRIBUTING.md).
b. Ensure your .bashrc sets $LOCAL_DART_SDK
```
```shell
DART_SDK_REPO_DIR=<Path to cloned dart sdk>
export LOCAL_DART_SDK=$DART_SDK_REPO_DIR/sdk
```
```
c. The local checkout is at main branch: git rebase-update
Your Flutter SDK in tool/flutter-sdk and the one on PATH are updated to the latest candidate release branch:
- Run devtools_tool update-flutter-sdk --update-on-path
You have goma configured

Prepare the release

Create a release PR

[!NOTE] If you need to install the Github CLI you can run: brew install gh

Ensure that you have access to devtools_tool by adding the tool/bin folder to your PATH environment variable

MacOS Users
- add the following to your ~/.bashrc file.
- export PATH=$PATH:<DEVTOOLS_DIR>/tool/bin
  [!NOTE]
  Replace <DEVTOOLS_DIR> with the local path to your DevTools repo path.
Windows Users
- Open “Edit environment variables for your account” from Control Panel
- Locate the Path variable and click Edit
- Click the New button and paste in <DEVTOOLS_DIR>/tool/bin
  [!NOTE]
  Replace <DEVTOOLS_DIR> with the local path to your DevTools repo path.

Run devtools_tool release-helper in order to:
- create a new branch using the tip of master and check out locally
- create a PR for the branch
- update your local version of flutter to the latest flutter candidate
  - This is to facilitate testing in the next steps
NOTE: Run the script from /devtools/tool while the issue is not adderessed.

Verify the version changes for the Release PR

Verify the code on the release PR:

updated the devtools_app and devtools_test pubspec versions
updated all references to those packages in other pubspec.yaml files
updated the version constant in packages/devtools_app/lib/devtools.dart

devtools_app and devtools_test versions are updated in lock, so we don't have to worry about versioning between these two packages. The other DevTools packages, however, are not updated in lock and each have their own versioning. For devtools_app_shared, devtools_extensions, and devtools_shared, we adhere to semantic versioning strategy where breaking changes should be versioned with a major version bump, and all other changes should be minor or patch version bumps.

Test the release PR

Build DevTools in release mode and serve it from a locally running DevTools server instance:
```
devtools_tool serve
```
Launch DevTools and verify that everything generally works.
- open the page in a browser (http://localhost:53432)
- flutter run an application
- connect to the running app from DevTools
- verify:
  - pages generally work
  - there are no exceptions in the chrome devtools log
- If you find any release blocking issues:
  - fix them before releasing.
  - Then grab the latest commit hash that includes
    - the release prep commit
    - the bug fixes,
  - use this commit hash for the following steps.
Once the build is in good shape,
- revert any local changes.
```
git checkout . && \
git clean -f -d;
```

Submit the Release PR

Receive an LGTM for the PR, squash and commit.

Tag the release

Checkout the commit from which you want to release DevTools
- This is likely the commit, on master, for the PR you just landed
- You can run git log -v to see the commits.
Run devtools_tool tag-version
- this creates a tag on the flutter/devtools repo for this release.
- This script will automatically determine the version from packages/devtools/pubspec.yaml so there is no need to manually enter the version.

Wait for the binary to be uploaded CIPD

On each DevTools commit, DevTools is built and uploaded to CIPD. You can check the status of the builds on this dashboard. Within minutes, a build should be uploaded for the commit you just merged and tagged.

[!NOTE]
If the CIPD build times out, instructions for re-triggering can be found at go/dart-engprod/release.md

Update the DevTools hash in the Dart SDK

Run the tool script with the commit hash you just merged and tagged:

devtools_tool update-sdk-deps -c <commit-hash>

This automatically creates a Gerrit CL with the DEPS update for DevTools. Quickly test the build and then add a reviewer:

Build the dart sdk locally

cd $LOCAL_DART_SDK && \
gclient sync -D && \
./tools/build.py -mrelease -ax64 create_sdk;

Verify that running dart devtools launches the version of DevTools you just released.
- for OSX
```
xcodebuild/ReleaseX64/dart-sdk/bin/dart devtools
```
- For non-OSX
```
out/ReleaseX64/dart-sdk/bin/dart devtools
```
If the version of DevTools you just published to CIPD does not load properly, you may need to hard reload and clear your browser cache.
Add a reviewer and submit once approved.

Publish DevTools pub packages

If package:devtools_app_shared, package:devtools_extensions, or package:devtools_shared have unreleased changes, publish these packages to pub.

From the respective devtools/packages/devtools_* directories, run:

flutter pub publish

Update to the next version

gh workflow run daily-dev-bump.yaml -f updateType=minor+dev This will kick off a workflow that will automatically create a PR with a minor + dev version bump. That PR should then be auto-submitted.
Make sure that the release PR goes through without issue:
- See the workflow run here
- Go to https://github.com/flutter/devtools/pulls to see the pull request that ends up being created

Verify and Submit the release notes

Follow the instructions outlined in the release notes README.md to add DevTools release notes to Flutter website and test them in DevTools.
Once release notes are submitted to the Flutter website, send an announcement to g/flutter-internal-announce with a link to the new release notes.

Cherry-pick releases

Prepare the release in the `flutter/devtools` repo

Find the DevTools tag that you want to perform the cherry-pick release on top of. Then checkout that tag locally. For this example, we'll use v2.29.0 as the base branch and 2.29.1 as the cherry-pick branch.
```
git checkout v2.29.0
```
Create a new branch for your cherry pick release.
```
git checkout -b 2.29.1
```
Cherry pick the commit(s) you want in this cherry-pick release, and bump the DevTools version number:
```
git cherry-pick <commit>
devtools_tool update-version auto -t patch
```

Commit your changes and push to the upstream remote.

git add .
git commit -m "Prepare cherry-pick release - DevTools 2.29.1"
git push upstream 2.29.1

To move on to the next step, you will need to take note of two values:

The name of the DevTools branch you just created (e.g. 2.29.1)
The commit hash that is at the tip of this branch (see https://github.com/flutter/devtools/branches).

Manually run the DevTools Builder

Follow the instructions at go/dart-engprod/devtools.md#cherry-picks to trigger the DevTools builder.

Create the cherry-pick CL in the Dart SDK

Checkout the Dart SDK branch you want to perform the cherry-pick on top of (e.g. stable or beta), and create a new branch:

git new-branch --upstream origin/<stable or beta> cherry-pick-devtools

From this branch:

Edit the "devtools_rev" entry in the Dart SDK DEPS file to point to the cherry-pick release hash (the commit at the tip of the cherry-pick branch you created above).
[Only if cherry-picking to stable] add a CHANGELOG entry.

Commit your changes and upload your CL:

git add .
git commit -m "Cherry-pick DevTools 2.29.1"
git cl upload -s

Once your CL is uploaded to Gerrit, modify your changelist commit message to meet the cherry-pick requirements.

Then trigger a CQ Dry Run, add reviewers, and wait for approval. DO NOT merge the CL yet.

Create the cherry-pick issue in the Dart SDK

Follow the Request cherry-pick approval instructions to create a cherry-pick request against the Dart SDK.

Once the Dart release engineers approve both your cherry-pick issue and your cherry-pick CL, you can merge the CL you created above.

Do not move on to the next steps unless your cherry-pick CL has been approved and merged.

Create a DevTools tag for the cherry-pick release

If your cherry-pick CL has not been approved and merged, wait.

Once your cherry pick has been approved and merged, create a tag for this cherry-pick release. This will ensure that we have a tag we can branch from if we need to create another DevTools cherry-pick release from the tip of the one we just created.

Check out the cherry-pick branch you created earlier, and create a git tag:

git checkout upstream/2.29.1
devtools_tool tag-version

Create the merge commit in the `flutter/devtools` repo