Open version range, update gradle

[westy92]

Description

One Line Summary

Open version ranges and update gradle.

Details

Motivation

Remove the need to release this SDK every time the Android or iOS minor/patch version changes.

---

This change is 

[nan-li]

Hi @westy92,

Thank you for submitting this PR. I can see the benefits of opening the range version, but it can lead to inconsistencies and bugs when the OneSignal Flutter SDK uses a newer version of the native OneSignal SDK than expected.

For example, we are not sure what the native OneSignal Android SDK will look like by v5.7.0, so it should not be used by the OneSignal Flutter v5.0.0 SDK.

Keeping it consistent and allowing app developers to fork and modify the Flutter SDK for their needs is the best compromise.

[westy92]

Hi @nan-li,

This should not be an issue if OpenSignal adheres to semantic versioning. As long as the major version doesn't increase, there should be no breaking changes.

If this change isn't desired, could you please include in your Android/iOS release process a step to bump the Flutter SDK version number? It is often lagging behind. (The main motivation for this PR)

[nan-li]

This should not be an issue if OpenSignal adheres to semantic versioning. As long as the major version doesn't increase, there should be no breaking changes.

If this change isn't desired, could you please include in your Android/iOS release process a step to bump the Flutter SDK version number? It is often lagging behind. (The main motivation for this PR)

Hi @westy92 I do apologize for the SDKs lagging behind the native Android / iOS releases. We will be releasing an update on all the cross-platform SDKs and moving forward, making updates more frequently.

You are right, using semantic versioning will prevent breaking changes, but there are some internal APIs from the native SDKs that are meant only for internal use on our "wrapper" SDKs and those may change.

[westy92]

Thank you for the context and Flutter SDK updates!