Incorrect Dart support policy #968
Comments
Thanks for opening this issue!
|
|
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. |
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. |
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.
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. |
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!
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] |
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 But when we want to use a package in our package that supports version 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 |
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:
Let's take a look at the min SDK distribution:
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 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. |
Yes, it is a good suggestion |
|
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 |
|
Great discussion! It's interesting that I had a similar versioning issue with a different, but popular, package #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? |
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.
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. |
|
@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? |
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? |
|
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. |
|
I want to add my struggle with current policy. Previously it was with http package. Major package was already updated to latest http package but Parse SDK wasn't which was causing dependency issues. You may be asking why I need to upgrade. It's because I like to keep my app up-to-date and I have maintenance at the end of the month. I do upgrade, test and deploy each month so I don't have to deal with huge amount of changes Flutter ecosystem introduces later on. Another issue I recently got when compiling my app for iOS 18 when using Firebase. There is an issue with iOS 18 and older Firebase plugin version. It just won't compile. Fix is to update the firebase plugin to latest version. But release cycle don't let me update it because of dependency of Parse SDK with lower version of dependencies. There will be huge changes in 6 months of time span. Policies are made to make things in order but if it's breaking the system we should change the policy. Instead of sticking to policy we should be prioritizing developer issues. |
|
What is your policy suggestion in context of the arguments made previously in this thread? |
I would say decrease the update time from 6 months to 3 where we do upgrade regularly every 3 months. Then we also take new issues into consideration. If someone reports a issue about dependency then we fix it immediately instead of waiting another 3 months. |
That sounds like a contradiction. Why wait 3 months, if we wait 0 when someone requests a dependency upgrade? The policy would then basically be, "upgrade every dependency as soon as possible". The reason why we didn't go with that is explained in #968 (comment). Please feel free to counter the argument made there. |
|
No it's not a contradiction.
Doing so, we get both regular update every 3 months and still fix developer issues. |
|
That sounds too arbitrary, why 3 months, why not 2 or 4? A complaint is not a technical basis for making a decision, it's just an unconditional action. That's the contradiction to the 3 months condition. It's also unclear how you define a complaint. What if someone opens an upgrade PR without technical necessity, or if an automated process open a PR as soon as a new version becomes available? Your suggestion is not addressing the arguments made previously, which give a reason for why the policy is currently as it is, based on an analysis of how other popular libraries support historic dart versions. |
I think you are misunderstanding package dependency version with flutter SDK version. The comment in #968 (comment) is about SDK version. I am not complaining about it. It is the package dependency we need to resolve. And why are you arguing on months 2 or 4? We should pick whatever considering both maintainer and Parse SDK user. |
As I understand it, these two are related to each other. The reason why we cannot upgrade some dependencies is because they increase the required min dart / flutter version which is higher than the dart / flutter version the Parse SDK is required to support according to its current support policy. See for example this comment. If a dependency can be upgraded without requiring to modify the SDK's dart / flutter version, then we can always do that. In fact, such dependencies should be upgraded as soon as possible for bug fixes and security. Our support policy currently doesn't define a hold-off time for that.
Whatever number we pick, it should have a factual basis on data. Otherwise 3 months is as good as 6 months. But again, to be clear, this issue here is not about "how long we wait until we upgrade a dependency", it's about "how long should the SDK support a dart / flutter version", which then defines - for some dependencies - the earliest date we can upgrade them. |
|
You can not relate Dart/Flutter SDK with package dependency since every package depends on Dart SDK. Package maintainers do not need to change dart SDK constraints frequently since the constraint we get when creating a project is already enough. If I create a dart package now I will get SDK constraints Updating |
|
I think as long as there's no breaking changes, we should be able to update the SDK, I think someone mentioned earlier, most update as long as it does not have any new future is for bugs and security update so as a developer it is good to keep up with these updates |
How is that possible if dart 3.5.0, 3.6.0 and 3.7.0 each already contain breaking changes? In my understanding, the dart and flutter SDKs don't follow semver and breaking changes are introduced at a feature version level. That's why in our compatibility table we distinguish by feature version, and our CI tests the SDK for each version. In fact, I seem to remember that we had to make code adjustments in the past for the CI to pass for all these feature versions. To recap the earlier comments in this thread and outline the chain of events:
Important that (3) and (4) apply to every developer who uses the Parse SDK, not just the developer who requests the dependency upgrade in (1). I believe I understand what the designers of the dart ecosystems intended, which seems to be to force developers and library maintainers into a continuous upgrade cycle. However, this creates the challenges we're faced with here. My interpretation of this is a fundamental flaw in the frequency in which dart introduces breaking changes (only ~2-3 months between releases) and the transient dependency management (only 1 single version of a dependency in a project). We can only try to mitigate that, and as we do, we're trying to balance the need of the developer in (1) vs. the effect on the developer in (3) and (4). |
All of this points to dependency issue. The only question is how we are trying to fix the dependency issue. Holding back upgrades is not helping at all. |
|
At least we can try making ParseSDK compatible with other major packages and latest Flutter version. I never suggested to upgrade the package as soon as there is new version if you think so. |
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.
The text was updated successfully, but these errors were encountered: