Allow marking specific package versions as "broken"

[kevmoo]

We need a way to handle "oops" publishes.

Examples:

• analyzer 0.30.0+3 – worthless, need +4
• analyzer 0.30.0+1 – also broken, need +2
• isolate 1.1.0 - bad SDK constraint. Allows older Dart versions to get package that uses generic methods - which causes crashes.
  • Fix PR here - Fix oops with 1.1.0 release – only support SDKs w/ generic functions dart-archive/isolate#17

[kevmoo]

Related to #289 – although I think there are seperate concepts

[isoos]

What do we need to do with them, e.g.

• Hide?
• Delete (from Datastore and blob storage)?
• Mark them as broken? (how?)

[kevmoo]

Current idea:

• By default, don't return them when accessing https://pub.dartlang.org/api/packages/async
• Or, return them, but flagged broken
• Then add options to the pub client to "do the right thing" – let a user override, etc...

Highlight them as broken in the version list. If it's the "latest" one, maybe show the one before by default and give a pointer to the broken one in a subtle way

[isoos]

Why not just delete them? (Related: who gets to approve what to consider broken?)
If they are truly broken, there is no reason for anybody to rely on them or use them, is there?

[kevmoo]

There is some weirdness. If a user (for some reason) has depended on a broken package, we have a bit of a promise to honor it. We want pub to "feel" immutable.

[mkustermann]

Is that the same as #289 ?

[mkustermann]

There have been discussions about this before, here are a few points:

• usually constraints don't contain <a.b.c>+... as upper bound, so if a package fixes the problem by doing a bugfix with a +1 all clients will get the fixed version.
• only the uploader has the right do change anything, mark it deprecated/buggy/whatever
• we should avoid deleting as much as we can, since users might have pubspec.lock files which refer to these versions. If we delete them a pub get which used to work will suddenly fail
• there is the question what happens if an author accidentally uploaded a package with confidential information in it (e.g. ssh keys, passwords, ...): this is one of the few cases which supports the deletion case (even though the uploader should consider everything as being leaked the moment he published it)

Before implementing something, we should give it enough thought and come up with a good design and let other people provide feedback on the design.

I don't think this has super high priority, in particular given all the other things that are on the road map.

[kevmoo]

Before implementing something, we should give it enough thought and come up with a good design and let other people provide feedback on the design.

Agreed! We should do zero impl here (yet). Just tracking it.

I don't think this has super high priority, in particular given all the other things that are on the road map.

Also agree.

[mit-mit]

Specific idea discussed:

• Allow publishers to mark a specific version as 'broken'
• On a package page, show the broken versions as such
• On the package list page, show the latest version not marked broken
• If pub asks for a specific version, and that is known broken, still return it
• if pub asks for a list of versions (eg. in pub upgrade), exclude the broken versions from the list