Semantic versioning of interface

[renefloor]

This is not an issue about a specific feature, but about the versioning policy of the webrtc-interface.

The interface package has many breaking changes that are published as minor or patch versions.
Some examples of breaking changes:

Changing method interface
Adding new getters
Renaming methods

If you publish a new version of the interface with a minor change it should work on existing implementations without updating them. If they don't, it should be publish as new major version. Updating with a major version is not ideal, but also not a bad thing. The interface is hardly ever used directly, so if you are already on version 10 that's not a big issue.

The Flutter team has a pretty strict policy to prevent breaking changes in the interface as much as possible, which is a good thing in general.
1 way to do this is to always add a default implementation with an UnimplementedError if you add something to the interface. When other devs extend the interface (instead of implement) the existing package will work fine with the new version of the interface and the new method will probably never be called so the error will also not show. You can learn more about this in their guidelines: Breaking changes to plugin platform interfaces and Changing platform interface method parameters

Even when you just have a regular dev depending on flutter_webrtc they might bump into the issue you are creating.
For example, you change the interface like you did before, without a new major version. You update flutter_webrtc, but for example with a new major version of path_provider. If the dev would add flutter_webrtc to an app that uses the old path_provider it will take the latest version of the interface with a less old version of flutter_webrtc. Following semantic versioning they are compatible, but in reality it won't compile.

[cloudwebrtc]

@renefloor thanks for pointing it out. Yes, this does cause some issues. In the recent update, I read the docs you linked, which will be of great help to the maintenance of flutter-webrtc. I will first release a hot fix to avoid affecting some flutter_webrtc fork implementations that rely on webrtc-interface. Maybe the problem is that there is no clear contribution document to guide contributors on how to avoid these impacts. I also learned some lessons/knowledge from it. In short, I want to make flutter-webrtc better. Face these problems and make corresponding changes.

Due to some historical reasons, it was split into webrtc-interface, dart-webrtc and flutter-webrtc, which does not meet the interface specification of flutter plugins, so I am thinking of modifying these packages (split into multiple packages, flutter_webrtc, webrtc_interface,
flutter_webrtc_{android,apple,html,windows,linux....}).
And add some contribution guidelines, and some CI to avoid the above issues. I think this is also a necessary change for the 1.0 release

[renefloor]

Thanks for the response. We're here to learn from each other, I think you're doing great work with this package and maintaining open source packages and plugins isn't easy.

I think the split in dart/native like you have now is pretty ok. The main benefit of full federation (with a package for each platform) is that if you have any missing platform it can be implemented by anybody and added to the app. Splitting into more packages also increases the overhead of maintaining them. If you do, the current webrtc_interface is still fine to use as platform interface package.

[cloudwebrtc]

I retracted the latest version. and released webrtc_interface: 1.2.2+hotfix.2 to make the historical version work. This will cause some dart analyzer warnings in flutter-webrtc, but will not affect compilation and running. A major version will be released in the version after the API adjustment