Description
With #26 we added a version number to to the BuildConfig
and BuildOutput
.
The way this works is that the SDK passes the version of the protocol that has rolled in to the Dart (and Flutter) SDK. If a user's build.dart
cannot deal with that, the build is supposed to fail.
Similarly, the build.dart
passes its value of the protocol in the build output. The Dart (and Flutter) SDK check the version and error if the output cannot be used.
@jonasfj suggested that we could use the Dart SDK version instead of the a version number in the protocol and use the SDK lower bound on the package being build to determine what version of the BuildConfig
to provide to a package. The main benefit of this approach would be that if we need to do a breaking change to the build configuration, we don't end up in a situation where all dependencies with native assets need to be migrated before developers can update their Dart / Flutter SDK.
If the resolved package:native_assets_cli
dependency in the package uniquely determines the protocol version (e.g. all protocol version bump also are a package version bump) we can also support the same behavior by looking at version of that package a package requires.
(With both approaches, the implementation in package:native_asset_cli
needs to have a version number in the build config construction so it can keep constructing older versions.)
Metadata
Metadata
Assignees
Type
Projects
Status