Closed mtrezza closed 10 months 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.
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?
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.
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.
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]
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.
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!
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.
Great analysis, I'm convinced, but what do you suggest? Is the support period the same as one year?
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.
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
Would you want to do the honors? 🙂
Would you want to do the honors? 🙂
Sure 😃
I think I should change ci too
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.
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.