I think you should consider being a little slower in the move to dart 3.0

[insinfo]

@isoos @simolus3

I saw they put dart 3.0 as the minimum supported version, I think as a database driver being a lower level package it should be more stable and have less changes that may affect many users who cannot change the version of dart with each release, because of other project dependencies or even because they may be small teams working on many projects, I think the driver has to be compatible with a wider range of dart versions to ensure it makes it to the majority of users. package users, many users are still stuck on dart 2.18.
I think this should be considered so that your users stuck on dart 2.18 can access bug and feature updates for a slightly longer period of time.

I think stability and compatibility is very important for users of a library/package

Besides dart 3.0 doesn't bring huge improvements in performance, it's more about adding syntax features, I think it could wait a little longer before this significant change.

I'm more in favor of changes that don't have such a huge impact in terms of breakage that it stops users from upgrading.

[isoos]

I hear you. However, it is not like 3.0 came out yesterday, and we already upgrading to it. I think people who are not upgrading to Dart 3.0 after almost 4 months now (which is a mostly a non-breaking upgrade), probably won't want to migrate their API to package:postgres 3.0.0 either. In other words, I think there is very little overlap of wanting to upgrade package:postgres indefinitely, but keeping the SDK on 2.17.

[insinfo]

dart update pace is very fast, 4 months is too little time, i think the driver could have a slower update pace to ensure more compatibility i think i could update to dart 2.18 now and when dart 3.3 release go to dart 2.19 keeping a constant delay of 3 or four versions of dart,

this is one of the reasons why banks and large companies adopt java because it is very stable.

[isoos]

And that is fine. People on 2.17-2.19 are still able to use package:postgres 2.x. If somebody is conservative in upgrades, they won't want to migrate to postgres 3.x right away anyway.

[insinfo]

i think the user shouldn't be forced to change dart version just because a package added some improvements and bug fixes, i'm not saying that we have to stay indefinitely with the same dart version so i'm suggesting that this changes be a bit more slow

[simolus3]

Also adding my two cents since I was mentioned:

I think this should be considered so that your users stuck on dart 2.18 can access bug and feature updates for a slightly longer period of time.

Will the Dart team release bugs and feature updates for Dart 2.18 for a longer period of time too? If you don't want to update - fine, but I don't understand why one would want to not update some core components and sill expect everything else to be up-to-date.

By doing a major version increase, we can also keep supporting 2.x releases without Dart 3 after the initial postgres 3.0 release.

Perhaps it was unfortunate that the change requiring Dart 3.0 has been published with a 2.x version tag to support the experimental API import. That's probably something we should revert after the stable 3.0 release (by removing the v3 API from a stable 2.x release I guess).

Besides dart 3.0 doesn't bring huge improvements in performance, it's more about adding syntax features, I think it could wait a little longer before this significant change.

Updating to Dart 3.0 isn't that breaking though, is it? The change is that you're now forced to support null-safety (which does enable performance improvements), but you can still chose to use a language version of 2.18 with the Dart 3.0 SDK.

I'm more in favor of changes that don't have such a huge impact in terms of breakage that it stops users from upgrading.

The v3 version of the package will also come with new API, which is likely a bigger breakage than the change of the SDK version constraint.

It's probably fine not to update immediately once it comes out, but it also adds new features that would be very cumbersome to include in the v2 API (like explicit control over prepared statements). Since we're going to do a breaking release either way, we might take a few more breaking options as well.

this is one of the reasons why banks and large companies adopt java because it is very stable.

Outside of Java 8, it's not like you get infinite support lifetimes for Java as well. The stability argument mostly refers to the fact that a program compiled with javac from JDK 11 runs just fine against the latest JVM. This is kind of similar with Dart - as long as you're using null-safety (which came out more than two years ago), no source code changes are necessary to adopt the 3.0 SDK.

[insinfo]

...no source code changes are necessary to adopt the 3.0 SDK.

unfortunately this is not quite the case because any user who uses the postgres package in a project that depends on another package that uses the dart analyzer package is stuck, because in general the analyzer package undergoes many changes that involve a lot of code changes.

I'm not saying that we shouldn't update the minimum version of dart, I'm just saying that it should happen a little slower. Just because the dart team updates all the time and gives support for a very short time doesn't mean that we should also do the same, I don't think this policy of the dart team to support for such a short time is a good thing.
I think you can follow an approach close to the .NET LTS, maybe a middle ground because the .NET LTS has 3 years of support.

https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

[insinfo]

I didn't say java has infinite support, I just said it has longer support.
Oracle intends to support Java LTS versions as follows:

Java 7 by 2022
Java 8 until at least 2030
Java 11 by 2026
Java 17 until at least 2029

I'm not saying we have to be stagnant and stuck in one version for so long, but be a little slower and more cautious about it.

[isoos]

I think that it is unrealistic that we will support >=2.17 SDK for years to come. A few of the dependencies in package:postgres are already on >=2.19.

I've just looked at package:analyzer: it is already on >=3.0 for about 2 months, and I imagine every code generator that depends on source code analysis will depend on 3.0 SDK soon (explicitly or implicitly). A random sampling on the most recently published versions on pub.dev shows that about half of the recent packages are already on >=3.0.0 explicitly. An older pubspec dump of mine has more than 3000 packages already on 3.0+. We may not be explicit about 3.0 requirement, but our dependencies and other app dependencies will make it implicitly anyway.

I could be convinced to consider a reasonable period - if we have a measurable rule to follow. Otherwise now is just as good as two months later.

[isoos]

I should add: I have one codebase that is on 1.x SDK, and another two that are on 2.8 - without any plan to upgrade them. These apps are mostly done, and unlikely to get any upgrade. If they need something from a newer dependency, I will consider upgrade or rewrite, but otherwise, small fixes are fine using the currently resolved ones.