Remove uses of `package:archive`

[natebosch]

The archive package doesn't appear active and I can't find a strong reason this functionality needs to be in this package. I don't see any usages internally or in Dart team owned packages, nor do I see a usage in sass. If this is still needed elsewhere it should be possible to implement as a separate package.

[jakemac53]

This will happen as a part of the null safety release

[nex3]

In the future, my team would really appreciate it if you consulted with us before deleting APIs that we depend on. In this case it's feasible enough for us to just copy ArchiveDescriptor into our own repository, but breaking decisions need to be made together with stakeholders rather than unilaterally.

[natebosch]

In this case it's feasible enough for us to just copy ArchiveDescriptor into our own repository

That was the driving factor in an off-thread discussion. We plan on being more careful when it's less trivial to duplicate the functionality in a separate package.

[natebosch]

One good way you can be sure to get proactive warnings about API changes that impact you is to have the code in google3 - that way we'd send a CL or start a discussion.

[nex3]

That was the driving factor in an off-thread discussion.

We need to be party to these discussions before decisions are made. We're stakeholders in the behavior of these packages, and part of being a responsible maintainer of an open-source package is involving stakeholders in discussions of breaking changes.

One good way you can be sure to get proactive warnings about API changes that impact you is to have the code in google3 - that way we'd send a CL or start a discussion.

It's not realistic for us to import all of our open-source infrastructure into google3 just so it's easier for you to run tests against it. I'd be happy to provide you an overview of the Dart packages we maintain externally so you can check them that way, but I think the easiest thing for both of us would be if you just looped us in on any discussions about breaking changes to core Dart packages. If they won't affect us, it's easy enough for us to just give the thumbs-up.

[leafpetersen]

We're stakeholders in the behavior of these packages, and part of being a responsible maintainer of an open-source package is involving stakeholders in discussions of breaking changes.

What do you think would be a reasonable and feasible way to alert stakeholders to upcoming breaking changes? For the core libraries and the language we announce in the issue tracker and on the mailing lists. Packages are versioned, so breaking changes are less of an issue, but perhaps we should consider having a similar process for our core packages?
@lrhn @natebosch @mit-mit should we consider a breaking change announcement policy as part of your proposed core package process updates?

[lrhn]

Breaking changes in packages should happen for a reason. We can expose that reason in a breaking change message, but it's unlikely that stakeholders will be able to prevent the change.

Packages are versioned, and you can stay on the old version for a while, but obviously it's not a long-term solution. If the package doesn't get a null safe version, then it's effectively dead. It's more reasonable that stakeholders can ask to keep the old version alive and supported for an extended amount of time.

Until now, packages have not come with SLAs. We plan to change that in the future, with different levels of support guaranteed for different groups of Dart Team owned packages. At the highest level of support, that should probably extend to keeping the API alive and supported for a specific amount of time after a change notification, so even if we say that a specific version is end-of-life'd, and we publish a new major version with a different API, we'll still keep it going for (perhaps) six months with all necessary updates including language migration, if at all possible. (Not sure how we'd do the versioning, though, if we have 2.x and 3.x versions both active, and we want to do a null safety migration of both, then we can't do a major version increment of the 2.x version. I guess we could move them to 4.0 and 5.0 if we're doing both.)

So, even with a breaking change notification, and a release with a major version increment, we'd still support the old version for some amount of time. The precise amount of time would differ for different types of packages, and we'd probably be able to extend the support in case there is an important need for it.

That's what I'd suggest.

[jakemac53]

Fwiw what @lrhn suggests is essentially the informal current situation (for the actively maintained packages at least), minus the part about language migration which I do not think we should offer support for. I don't see a reason that we should offer that level of support, as language versioning should ensure the old package will continue to work.

We can and do backport necessary bug fixes, as is reasonable, and only on request. This would include fixes for breaking changes in the SDK that are not language related. I would be fine with codifying a policy similar to that.

As far as breaking change notifications, I think that filing issues on the issue tracker, and mentioning the changes in the CHANGELOG.md file, should be sufficient. That is exactly what happened in the case of this package/breaking change.

[lrhn]

True, there might not be much advantage in migrating the old version to a new language version. It will keep working, and you can always migrate to the new version if you're going to be migrating anyway. It's still impossible to use both the old version and the new version in the same program (the way our package resolution is currently working).
So, it comes back to which SLA we're offering for the package. Do we promise API stability for a specific number of months, or do we just promise that some version of the package will exist, but you might need to migrate to a new version if you want to be up-to-date.

I think we should consider back-porting bug-fixes to older versions/APIs for our high-SLA packages. Maybe promise bug fixes for six months (and that's actually a very short time) after each new stable release, even if we release a breaking change/new major version before that. Or maybe we want to designate some package versions as LTS (long term support) versions - you use this version, and we promise it will keep working and be bug-fixed and maintained for 18 months. That can even be a minor version, since we can keep the API completely stable.

[jakemac53]

I think we should consider back-porting bug-fixes to older versions/APIs for our high-SLA packages.

I would modify this to high priority bug fixes. Not all fixes have enough impact to be worth backporting imo. This could also include backporting additional fixes on demand.

Or maybe we want to designate some package versions as LTS (long term support) versions - you use this version, and we promise it will keep working and be bug-fixed and maintained for 18 months.

This should just be the latest version of each major stable release, whatever that is.

[natebosch]

I would modify this to high priority bug fixes. Not all fixes have enough impact to be worth backporting imo. This could also include backporting additional fixes on demand.

+1 on backporting fixes on demand. We could maybe extend that to backporting fixes for packages that are still getting downloaded at a certain rate from pub. I don't want to get into a situation where we are backporting fixes that no one sees or cares about.