search

parse-community / Parse-SDK-Flutter

The Dart/Flutter SDK for Parse Platform
https://parseplatform.org
Apache License 2.0
575 stars 189 forks source link

Add Dart / Flutter framework support policy #872

Closed mtrezza closed 1 year ago

mtrezza commented 1 year ago

New Feature / Enhancement Checklist

Current Limitation

The Parse SDK is missing a policy that defines when support of a Dart / Flutter framework version should be dropped.

Feature / Enhancement Description

Add a support policy depending on the LTS policy by the framework publishers, or if there is no such policy, according to community best practice.

parse-github-assistant[bot] commented 1 year ago

Thanks for opening this issue!

mtrezza commented 1 year ago

Dart and Fluter don't seem to have a LTS policy. It seems like an easy concept to just not issue a LTS policy, but it doesn't address the issue LTS is trying to solve, which is helping developers (and dependency maintainers like us) to plan how much time they have until their app becomes incompatible with its frameworks.

Someone could open a PR today that makes the Parse SDK require the latest release of Dart and Flutter. We probably wouldn't merge it because it would force developers to make their app compatible with the latest Dart / Flutter release in order to use the latest version of the Parse SDK. That again will lower adoption of the latest Parse SDK release among developers, which means we'll get less feedback on newer releases, etc. It's the fundamental issue LTS is addressing.

The suggestion in https://github.com/parse-community/Parse-SDK-Flutter/pull/867 is to bump to Dart >= 2.17.0, which was released in 11 May 2022, basically a year ago. So maybe we can just establish a minimum support Dart version that is at least 1 year old. That would mean that a developer has 1 year to make their app compatible with the Dart framework until their app may become incompatible with the Parse SDK. LTS is usually 2 years, but if the Dart / Flutter community is used to having to keep up in shorter cycles I think we can cut this down to 1 year.

If we apply the same to the Flutter releases, it seems the version that is at least 1 year old is Flutter 3.0.0, released on 11 May 2022 which requires Dart 2.17.0. Interestingly it's the same min. Dart version we'd support according to the policy above. To account for cases in which the required Dart version is lower than what the Parse Dart SDK supports, our policy could say "Flutter version at least 1 year old, or the Flutter version that requires the lowest supported Dart version by the Parse Dart SDK, whatever is higher."

catalunha commented 1 year ago

Dart and Flutter are evolving fast and changes in 1 year would be too big. Waiting 1 year would also leave many developers out of work. Because constant maintenance generates income. I would suggest somewhere around 3 months to 6 months. This way we follow the news, we have time to implement it and the group does not run out of work.

mtrezza commented 1 year ago

Interesting argument. I'm not sure whether developer income should be a deciding factor. The factor that seems critical is how much time a developer has until the app needs to be made compatible with newer Dart / Flutter frameworks. If we say 3 (or soon 6 months), then the Parse Dart SDK would require Dart 2.19 which is the latest Dart release, which creates the issues mentioned above.

mbfakourii commented 1 year ago

1 year is too long to adapt to new versions, I think even 1 month is enough because the changes in the new versions are not to the extent that many changes are needed.

I agree with @catalunha , maybe 3 months to 6 months is enough !

mtrezza commented 1 year ago

If we assume 3 months that means the Parse Dart SDK will require the latest "major" Dart release 2.19.0. Any developers whose app is not using at least 2.19.0 won't be able to use the SDK.

Similarly, if a developer uses another dependency that hasn't been released for Dart 2.19.0, then they won't be able to upgrade the Dart version and the Parse SDK.

Are there any Dart / Flutter version adoption stats to better understand how many developers would be affected by this?

mbfakourii commented 1 year ago

@mtrezza Consider this if the user does not migrate to the new Dart, but the package migrates. It is still possible to use the new package in the project with the old Dart! (I tested)

That is, if the user uses sdk: ">=2.12.0 <3.0.0 in his project, but our package uses sdk: ">=2.17.0 <3.0.0. The user can still use the package that uses the new sdk: ">=2.17.0 <3.0.0!

mtrezza commented 1 year ago

That's a good point. How is it even possible that the Parse Dart SDK pubspec currently says:

 environment:
  sdk: ">=2.12.0 <3.0.0"

For the Dart framework a minor version may contain breaking changes. So we don't even know yet whether the Parse SDK will be compatible with Dart 2.20.0, do we?

It seems to me that our CI is lacking a dart matrix. We are currently testing the SDK for architectures (macOS, Linux, Windows), but all the tests run with the single Dart SDK version 2.19.6.

To check compatibility we'd need to test with all minor versions within the current version range, from 2.12.x until 2.19.x, where x is the respective latest patch version. And since we cannot test unreleased versions, we cannot claim a <3.0.0 compatibility, which is essentially an open range. Instead, it should say:

environment:
  sdk: ">=2.12.0 <2.20.0"

The same goes for an app developer who cannot know whether the app will be compatible with sdk 2.20.0, so a sdk range of <3.0.0 for an app seems incorrect.

This all seems to stem from an inconsistency in the Dart world where apps and dependencies are explicitly expected to follow semver but the Dart SDK itself does not follow semver. A confusing design choice.

Nidal-Bakir commented 1 year ago

I will read and comment on this discussion tomorrow. I need to sleep now. I just wanted to let everyone know that Dart 3.0.0 has been released, and there is currently an issue with the Parse Flutter SDK for anyone using Dart version 2.19.x or higher. We need to get this resolved quickly.

see the PANA score

mtrezza commented 1 year ago

To move ahead we could:

Nidal-Bakir commented 1 year ago

merge https://github.com/parse-community/Parse-SDK-Flutter/pull/867 to set the supported Dart SDK to >=2.17.0 <2.20.0

This sdk: ">=2.17.0 <2.20.0" will prevent any Dart 3 users from using the SDK. We can not use this constraint.

fix https://github.com/parse-community/Parse-SDK-Flutter/issues/873 with another PR where we add support for Dart SDK 3 by setting the Dart SDK range >=2.17.0 <2.20.0 || >=3.0.0 <3.1.0 and adding a CI job that actually tests with Dart

The Parse Dart SDK is Dart 3 compatible. All we have to do is make the Parse Flutter SDK compatible Dart 3 by merging this https://github.com/parse-community/Parse-SDK-Flutter/pull/864 to remove the vsync param

Nidal-Bakir commented 1 year ago

We're making this too complicated. We should accept the nature of Dart and Flutter, and allow users to run the SDK on any version of Dart and Flutter. Testing the package against the latest version of Dart is good enough to spot any errors because the users of the package will always use the latest Dart version that the pub resolver can use respecting other package's constraints and the user-defined constraint for the Dart and flutter.

We did not spot the deprecated API (vsync param) because of the // ignore: deprecated_member_use comment above it. This comment suppressed any warnings by the analyzer.

https://github.com/parse-community/Parse-SDK-Flutter/blob/d7339cd3abc6455898228f9bd6fccc078012cd60/packages/flutter/lib/src/utils/parse_live_list.dart#L275-L276

Currently, we do not need the new features in Dart 3, The (Parse Dart SDK) is Dart 3 compatible.

All we have to do is set the constraint for the Parse Dart/Flutter SDK to sdk: ">=2.17.0 <4.0.0" and removing remove the vsync param to make the (Parse Flutter SDK) Dart 3 compatible.

By using this constraint sdk: ">=2.17.0 <4.0.0" we are telling the users that this package is compatible with any version of the dart that is greater than or equal to 2.17.0 and less than 4.0.0

So all we have to do is the next: merge in order:

Dart package:

  1. 860

  2. 867 (after we change the constraint to ">=2.17.0 <4.0.0" )

Flutter package:

  1. 864

  2. 868 (after we change the constraint to ">=2.17.0 <4.0.0" )

mtrezza commented 1 year ago

The Parse Dart SDK is Dart 3 compatible.

We strive for consistent quality measures across our products. One measure is that in order to officially claim compatibility, a CI test with the respective framework version is required. If we don't test, we don't make such a claim. Even thought it may be compatible.

We cannot claim >=2.17.0 <4.0.0, because Dart doesn't follow semver and there may be breaking changes in minor versions. All we currently know is that it's compatible with 2.19.x, that's the only version the CI is currently testing.

The solution to this is to add all dart versions to the CI for which we claim compatibility. I did that in #874 and added all tests from Dart 2.12 to 2.19. There we can see that the Parse SDK is actually not compatible anymore with Dart <2.18, because its dependencies require at least 2.18. So our current claim of >=2.12.0 <3.0.0 is incorrect, as would be >=2.17.0 <3.0.0, which is suggested in #867.

Nidal-Bakir commented 1 year ago

Alright, then we should do something like this: >=2.18.0 <=3.0.0? But then on every Dart release, we need to bump the upper bound so the users can use the SDK on it.

mtrezza commented 1 year ago

Yes, every 3 to 4 months (current Dart release cycle) someone needs to open a PR to:

The same for Flutter. I know that's a nuisance. It may be possible to automate the creation of these PRs, if someone wants to write a script for that. Until then we'd need to do that manually. On the bright side, it's a really simple PR anyone can submit.

Nidal-Bakir commented 1 year ago

Good point I'm with you on this. Should I update the constraint on the PRs to be >=2.18.0 <=3.0.0 ?

let's do that and write the support policy for this project.

mtrezza commented 1 year ago

I'll add the support policy in #874 by adding a compatibility table to the README of each package.

mtrezza commented 1 year ago

The discussions in https://github.com/parse-community/Parse-SDK-Flutter/pull/867 and https://github.com/parse-community/Parse-SDK-Flutter/pull/874 show that we are gaining important new insights into the SDK's compatibility with the new CI that runs tests with specific Dart and Flutter versions.

The support policy has been added in #874 and currently says that we'll support Dart and Flutter releases for 1 year since their release date to give developers time to upgrade their apps to use the latest Dart / Flutter release. If that turns out to be too long and cause issues for SDK maintenance, we can revise that in the future.

Closing via #874.

sgehrman commented 1 year ago

that parse_live_list code is totally worthless. put it in an example project. It's unusable and requires modification to even be useful. Just remove it. no one is using it.

mtrezza commented 1 year ago

@sgehrman This issue is closed and seems to refer to a different topic; please open a new issue if you would like to discuss the purpose of parts of the code.

pastordee commented 1 year ago

I use it thank you.