Open mtrezza opened 1 year ago
parse-github-assistant[bot]
commented
1 year ago 
mbfakourii
commented
1 year ago In my opinion, one year is too much time. If the developers are not interested in updating and using the new version, they can still use the old version of the package.
In my opinion, this policy also annoys the developers, it makes us unable to use new features for up to 1 year! And this actually slows down the development of the package.
mtrezza
commented
1 year ago it makes us unable to use new features for up to 1 year
Can you give an example of a new feature that is not available because we still support Dart 2.19?
mbfakourii
commented
1 year ago Can you give an example of a new feature that is not available because we still support Dart 2.19?
One of the new features of Dart 3 is Multiple returns, which allows us to have multiple output values in the function
Another point is that Flutter and Dart do not have a long lifespan and are developing and growing, I think they offer a new version almost every two weeks.
mtrezza
commented
1 year ago One of the new features of Dart 3 is Multiple returns, which allows us to have multiple output values in the function
The question is whether that impedes Parse SDK development, or it's just less convenient because it doesn't allow us to use the latest greatest Dart features when developing the SDK. For a developer who is using the Parse SDK this should be irrelevant as long as it's not affecting their own development. For Parse SDK maintainers that should be acceptable as long as it doesn't significantly increase maintenance effort.
I think they offer a new version almost every two weeks.
We only care for breaking releases (minor releases in the Dart world), which currently seem to happen about every 4-5 months. We could think about reducing the support time from 12 to 6 months, if we can find real examples that show a significant increase in maintenance effort because of the 12 months support. Also, if you could find Dart adoption statistics of apps somewhere, and we see for example that in the Dart world, 80% of developers upgrade their app to the latest significant Dart release within n months, we can adapt our support policy.
mbfakourii
commented
1 year ago The question is whether that impedes Parse SDK development, or it's just less convenient because it doesn't allow us to use the latest greatest Dart features when developing the SDK. For a developer who is using the Parse SDK this should be irrelevant as long as it's not affecting their own development. For Parse SDK maintainers that should be acceptable as long as it doesn't significantly increase maintenance effort.
In addition, it impedes development, it also prevents developers from using other packages that do not support versions below 3 !
For example, a package that does not support the version below Dart 3 cannot be in the same project as our package!
We only care for breaking releases (minor releases in the Dart world), which currently seem to happen about every 4-5 months. We could think about reducing the support time from 12 to 6 months, if we can find real examples that show a significant increase in maintenance effort because of the 12 months support. Also, if you could find Dart adoption statistics of apps somewhere, and we see for example that in the Dart world, 80% of developers upgrade their app to the latest significant Dart release within n months, we can adapt our support policy.
It is better to ask the question in the Dart repository.
Another thing is that all the packages that are currently available in Flutter packages, none of them support below 3! [1]
mtrezza
commented
1 year ago it also prevents developers from using other packages that do not support versions below 3 !
Are you talking about app developers, and if yes, why would that be? If someone wants to use Dart 3, they can do it as the Parse SDK supports it.
mbfakourii
commented
1 year ago Are you talking about app developers, and if yes, why would that be? If someone wants to use Dart 3, they can do it as the Parse SDK supports it.
I think I explained it wrong. For example, when a developer uses version 2.8 of Dart, in order to use a package that supports version 3 and above, he must update himself, which is not a problem on the developers' side.
But when we want to use a package in our package that supports version 3 and above, we encounter a problem in CI because it is not possible to use it in version 2.8 or 2.9.
If we skip from our CI and CI no longer checks the old versions below 3. When the developer adds our new version, he encounters a message that he should upgrade to the new version of Dart.
If the developer has secrets about using the old version of Dart, he can use the old version of our package!
And currently, most of the famous packages no longer support versions below 3. If you check the pub.dev site, you will understand this!
mtrezza
commented
1 year ago And currently, most of the famous packages no longer support versions below 3. If you check the pub.dev site, you will understand this!
Let's do a quick analysis.
There are two different aspects: "compatibility with Dart 3" vs. "required min Dart SKD version 3".
Looking at the packages listed on the overview page you linked we can see these min Dart SDK versions:
| Group | Min Dart SDK |
|---|---|
| Flutter Favorites | 2.12, 2.17, 2.14, 2.12 |
| Most popular packages | 2.18, 3.0, 3.0, 2.12, 2.18, 2.12 |
| Top Flutter packages | 2.18, 2.15, 2.12, 2.16, 2.17, 2.19 |
| Top Dart packages | 2.12, 2.12, 2.19, 2.12, 2.12, 2.12 |
Let's take a look at the min SDK distribution:
| Min Dart SDK | Count |
|---|---|
| 3.0 | 2 |
| 2.19 | 2 |
| 2.18 | 3 |
| 2.17 | 2 |
| 2.16 | 1 |
| 2.15 | 1 |
| 2.14 | 1 |
| 2.12 | 10 |
This is a bimodal distribution. The first peak (2.18) are the "moderate speed adopters" which take about a year (Dart 2.19 was released in Jan 2023) to upgrade. The second peak (2.12) is most likely a deliberate choice to support older Dart versions, because all of these packages are well maintained. An interpretation of this could be that 45% of the most popular Dart and Flutter packages still support Dart 2.12 to reach a broader developer audience and to make life easier for developers.
Looking at the firebase_core package as an example: the min SDK was raised to 2.18 in March 2023, but Dart 2.18 was released in August 2022. Developers had 9 month to upgrade their app, meanwhile they were able to upgrade the package with bug fixes and new features.
The fundamental problem with increasing the min Dart SDK version fast is that the time a package maintainer takes to make their package "Dart 3 compatible" varies. If an app has 10 packages and only 1 package requires a min Dart SDK version of 3, then all other 9 packages must be Dart 3 compatible in order to upgrade to Dart 3. Otherwise the developer must look for alternative packages that already support Dart 3 (higher development effort), or cannot upgrade to use the latest release of that one package that requires Dart 3, which can be especially challenging if a release contains a critical bug fix.
The developer is between the front lines of package maintainers. The more rapidly we increase the min Dart SDK version, the more difficult we make life for developers who use the Parse Platform SDK. We need to strike a balance, and I would say from the data above that balance is somewhere between Dart 2.18 and 2.12.
mbfakourii
commented
1 year ago Great analysis, I'm convinced, but what do you suggest? Is the support period the same as one year?
mtrezza
commented
1 year ago In time terms:
That means that the Parse SDK's support policy of 1 year is already on the lower end of the range. Unless there is a critical reason - which we would evaluate on a per-case basis - I would keep it at 1 year.
What we could do now is to open a PR that removes Dart 18 support (it's already >1 year old) and fix the wording in the support policy, which is the original issue opened.
mbfakourii
commented
1 year ago In time terms:
- Dart 2.18, released Aug 2022 -> time passed since release: 1 year + 1 month
- Dart 2.12, released Mar 2021 -> time passed since release: 2 years + 6 months months
That means that the Parse SDK's support policy of 1 year is already on the lower end of the range. Unless there is a critical reason - which we would evaluate on a per-case basis - I would keep it at 1 year.
What we could do now is to open a PR that removes Dart 18 support (it's already >1 year old) and fix the wording in the support policy, which is the original issue opened.
Yes, it is a good suggestion
mtrezza
commented
1 year ago Would you want to do the honors? 🙂
mbfakourii
commented
1 year ago Would you want to do the honors? 🙂
Sure 😃
I think I should change ci too
mtrezza
commented
1 year ago Yes, from the CI you'd remove Dart 2.18. And we should add Dart 3.1 compatibility. You could do this in 1 PR. The PR would be a feat PR because of the added Dart 3.1 compatibility, with a breaking change label because of the removal of Dart 2.18 compatibility.
chadpav
commented
1 month ago Great discussion!
It's interesting that I had a similar versioning issue with a different, but popular, package https://github.com/parse-community/Parse-SDK-Flutter/pull/1002 about 1 year later. All I'm saying is that there may be something to the Flutter community being new and evolving quickly that makes this discussion more interesting.
This issue resulted in me forking the Flutter SDK and fixing it locally. Later, I ended up realizing that I didn't need the functionality in the Flutter SDK and that the Dart SDK didn't have that dependency. So I switched packages. I even took the time to update the Flutter SDK package and submit a PR but was blocked due to the backward compatibility policy. It was the right call because we should respect the policies that we have in place. But in the end, I was frustrated and felt like I wasted several days on it.
Taking the other side I want to make a hypothetical argument. What would happen if we were to bump major versions of our SDK when backward compatibility breaks and keep up with the latest dependencies? If there were a critical bug on an older version of this SDK and a developer were stuck in maintenance mode they would be forced to patch an old release of the SDK or figure out a path forward through breaking changes?
We've seen at least two examples of the former. Would it be less pain to deal with the latter on an exceptional basis?
mtrezza
commented
1 month ago What would happen if we were to bump major versions of our SDK when backward compatibility breaks and keep up with the latest dependencies?
How would such a policy be clearly defined in practice, so that there are no discussions required in order to follow the policy? This is one important criteria, for efficiency and predictability. Currently it's clear; there is a simple time constraint on how long we support older Dart / Flutter SDKs.
If there were a critical bug on an older version of this SDK and a developer were stuck in maintenance mode they would be forced to patch an old release of the SDK or figure out a path forward through breaking changes?
We currently do not support LTS versions, so whatever issues occur in older versions are not considered. I don't see it viable for the Parse Flutter SDK in its current circumstances to introduce a LTS policy. Hats off to @mbfakourii for putting a lot of effort into contributing to the maintenance of this SDK. Adding LTS will significantly increase the required effort.
Great comment @chadpav, happy to revive this discussion.
mtrezza
commented
1 week ago @mbfakourii I've re-opened the issue and pinned it. Reason being that I'd like to review the policy since we've introduced it about a year ago.
We keep getting issue reports regarding dependency upgrades, and we sometimes have to reject them due to the support policy. For example:
Is the policy working and sensible as it is; should we improve anything?
mbfakourii
commented
1 week ago Is the policy working and sensible as it is; should we improve anything?
I think considering the many issues, it is better to change the time from 1 year to 6 months.
Another point is that I did not see support policy in many packages in Dart and Flutter
Is support policy really needed for Dart and Flutter packages?
mtrezza
commented
1 week ago A support policy is simply making sure we have a consistent approach and don't need to initiate a discussion every time we need to make a choice. We can define the support policy as we see fit. If the philosophy of Dart and Flutter is that we always strive to support only the latest version of Dart and Flutter and its dependencies, and drop support for older versions at any time, we could define that as well (although that's not what I have found in my analysis). We just can't have a discussion then to suddenly keep supporting an older version for some arbitrary reason, instead we'd follow that policy.
New Issue Checklist
Issue Description
It seems we have an mistake in our support policy, which says:
The end-of-support date needs to depend on how long a newer significant (=minor) release is available to give developers time to upgrade. Dart 3 has been released in May 2023. So we'd support Dart 2.19 until May 2024. That gives developers 12 months to upgrade.