Updating to new SDK releases

This page covers the procedures you might not remember to do when a new Dart SDK comes out.

What (not) to do

Obviously, you might to need to update text and examples to reflect the new release. Here's what else you might also want to do:

• Before the SDK is updated, consider testing the proposed release against the site's source code. This is easy to do on Travis, and just a bit harder to do locally. Instructions are in the next section.

• After the SDK is updated, consider doing the following:

  • Update the version displayed in the Dart 2 dropdown.
    To do this, from the top directory edit src/_data/pkg-vers.json.
  • Temporarily update .travis.yml to not test the dev channel if its lagging the stable channel causes test failures. (If you do this, file a bug to remind yourself to restore dev channel tests.) For an example, see this commit.
  • Add a banner to point to the release announcement.
    For an example of adding the banner, see PR #1234.

• Consider NOT updating the following:

  • The SDK version used by repo tools.
    This is controlled by the topmost pubspec.yaml. Unless you're updating the tools, there's no need to update this.

Testing a proposed SDK release

The .travis.yml file determines which SDK releases Travis uses to test source code.

Create a PR that changes the dart line in .travis.yml to include the new release. For example, to test the proposed 2.1.0 release, which lives under http://gsdview.appspot.com/dart-archive/channels/stable/raw/2.1.0/sdk/, change dev to stable/raw/2.1.0:

- dart: [stable, dev]
+ dart: [stable, stable/raw/2.1.0]

You could add additional releases, if you like: [stable, dev, stable/raw/2.1.0]

After you've uploaded that change and created the PR, Travis tests it. For an example, see PR #1227.

If you find any issues, download the release locally and fix the issues. Then retest using the same commands Travis uses (which you can find in .travis.yml).