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.

[nex3]

To be clear, although I definitely do also appreciate being notified when breaking changes are coming, what I'm specifically asking for here is being part of the discussion to decide whether those breaking changes should happen at all. It's important that you make those decisions multilaterally along with your major stakeholders.

[leafpetersen]

what I'm specifically asking for here is being part of the discussion to decide whether those breaking changes should happen at all. It's important that you make those decisions multilaterally along with your major stakeholders.

@nex3 Can you elaborate on what you're proposing here? That's a substantially different model of open source development than the Dart team has followed in the past, and not one that I'm convinced we have the resources to follow. Who are the major stakeholders? What is the process for identifying them? What is the process for negotiating changes? To what packages do these processes apply? Is this specific to Dart team owned packages, or is this something you are suggesting as a standard for published packages in general? Do you have a similar process for your own packages that you would suggest as a model?

[nex3]

I'm just proposing the same model that's used for Google-internal changes. Within Google, if you want to make a change that breaks code elsewhere in the repo, it's up to you to either fix that code proactively or to reach out to the team that owns the code and talk about what a migration path would look like and when they can budget for it. After all, we're all Googlers, and we all have the interests of our transitive users at heart 😃.

For Sass, we have a formal process for all changes that involves soliciting public feedback, with longer time horizons for breaking changes. I don't think that's necessary for something as simple as a change to a package, though—just an informal email thread would suffice.

[leafpetersen]

I'm just proposing the same model that's used for Google-internal changes. Within Google, if you want to make a change that breaks code elsewhere in the repo, it's up to you to either fix that code proactively or to reach out to the team that owns the code and talk about what a migration path would look like and when they can budget for it.

Right - and this is feasible for us because we have a clear path to identify and contact internal stakeholders, and a clear standard for how to measure the impact of changes (if the tests pass.... :) ) But in the open source world, we only know about a small subset of our users, and it's really not clear to me how to make that work.

For Sass, we have a formal process for all changes that involves soliciting public feedback, with longer time horizons for breaking changes.

That seems like a great process, but very heavyweight, no? Realistically, given that we're basically talking about one or two people spread out maintaining a large number of packages, I think that adopting something that detailed would slow us to crawl.

I don't think that's necessary for something as simple as a change to a package, though—just an informal email thread would suffice.

I guess what's not clear to me yet is where this email would go? dart-misc I don't think would really cover it. But individually collecting and curating email lists of stakeholders to notify for each of our packages would be very cumbersome. It seems to me perhaps to be more reasonable to have a policy that looks something like: "breaking changes will have an issue filed with a specific label, and if you're interested in having input you should watch that label and comment". Unfortunately, I'm not sure that github provides that functionality natively (I get notifications for some of our repos, but I think that's from a service that somebody on the team runs).

Maybe an alternative would be to have a specific list for package announcements, with the expectation that if you care about changes to Dart team owned packages you should subscribe?