search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.09k stars 1.56k forks source link

Investigate relaxing dart_api_dl.h version constraints #44376

Open dcharkes opened 3 years ago

dcharkes commented 3 years ago

We should consider changing the way the versioning in dart_api_dl.h works.

We changed the WeakPersistentHandles to become non-auto-deleting bumping the API version from 1.1 to 2.0. However, this meant that usage of the API of symbols that did not change also requires an API bump.

This in turn it requires an SDK version bump of the packages using this.

Background: https://github.com/google/webcrypto.dart/issues/4

mkustermann commented 3 years ago

We very rarely do breaking changes to the subset of APIs exposed via dart_api_dl.h. So I'm not sure if we need to change the versioning scheme or anything related to it. We do have a high bar for breaking changes.

jonasfj commented 3 years ago

Also older versions of package:webcrypto will not work with newer versions of the Dart SDK, yet, I can't update the SDK constraint in my already published package to reflect this.

Maybe we should make a package between the DL API, and other packages? Or allow packages to support multiple versions of the DL API.

Another option is to promise to not do breaking changes very frequently, and just hope that's good enough for now :D (it might very well be good enough for now)

mkustermann commented 3 years ago

Maybe we should make a package between the DL API, and other packages?

I assume it would be an empty package that has narrow SDK constraints. Its major version would change whenever Dart DL's major version changes. Each new Dart SDK would need to publish a new version to this package.

Effectively it would be a meta package versioning a subset of the Dart SDK, right?

Or allow packages to support multiple versions of the DL API.

A package can certainly look at (major, minor) version of the DL API and do different things, depending on the major version, possibly a slower dart-only fallback, using different .so file, ...

jonasfj commented 3 years ago

I assume it would be an empty package that has narrow SDK constraints. Effectively it would be a meta package versioning a subset of the Dart SDK, right?

We could be exposing NativeApi.initializeApiDLData from such a pub package -- it's a breaking change, and not something I've fully thought through yet. But it might even allow packages to support a version range of the ffi_dl_api package.

We have previously had some hacks that allowed a dart:_internal library to only be importable from a specific package:<name>/... URL.

A package can certainly look at (major, minor) version of the DL API and do different things,

Yes'ish.. I mean the current headers and C files you're supposed to embed doesn't lend itself towards this. I guess I would need to embed dart_api_dl.h and dart_api_dl.c for each major version of the DL API, leading to symbol conflicts I then have to work around.