| [](https://pub.dev/packages/frontend_server_client) | |
| [](https://pub.dev/packages/frontend_server_client/publisher) | |
| This package provides a client interface around the frontend_server compiler | |
| which ships with the Dart SDK. | |
| ## SDK Versioning Policy | |
| This package keeps a relatively tight version constraint on the SDK to allow for | |
| breaking changes in the frontend_server binary itself. | |
| Specifically, releases of this package will have an upper bound of less than the | |
| next _minor_ (middle) version number of the latest stable SDK. There are no | |
| requirements for the lower bound (other than the package must pass tests on that | |
| SDK). | |
| The effect of this policy is that breaking changes will be allowed to the | |
| frontend_server binary, but only in _minor_ SDK version releases. | |
| **Note**: This also means that when a new stable SDK is released, this package | |
| will also need a new version published on pub before users can get a valid | |
| version solve. | |
| ### Working with dev SDK releases | |
| By default, when you do a pub get/upgrade, a constraint like `<2.9.0` will | |
| actually allow dev releases of `2.9.0` if the current SDK is a dev release. It | |
| emits a warning when it does this, but will happily allow it. | |
| - This means that we don't have to publish versions that explicitly allow dev | |
| releases. We will be notified of breakages by our bots if a dev release does | |
| break us, and can release a patch. | |
| If we need to depend on some new feature from a dev release, the min sdk | |
| constraint should be bumped to that version but the max sdk constraint should | |
| _not_ be changed. So for example we will have constraints like | |
| `>=2.9.0-dev.1 <2.9.0`. |