kpm restore should not restore unlisted packages

[danroth27]

If we upload a set of packages as unlisted and the package dependencies are not all fully uploaded then kpm restore can break when a project is configured to use the latest packages. We should exclude unlisted packages when doing a package restore.

[jeffhandley]

Sadly, the logic is obscure and disappointing.

If the Published date value is 1900-01-01T00:00:00, then the package is unlisted and it should no longer be considered in dependency resolution when versions are being selected, or during initial installs of packages where users are discovering versions.

However, these "unlisted" versions must still be allowed when the user is restoring packages so that the version doesn't disappear out from under them and break their build.

This feature allows package authors to unlist packages for two reasons:

1. The package is being staged for an upcoming release announcement and they want to list the package at the time of the announcement.
2. The package has a very bad bug and the author doesn't want any new users to discover the version that has the bug.

This is implemented through the Published date field simply because it was an incremental change on top of the existing feed format that wouldn't break existing clients or servers.

For API v3, we've currently carried this logic forward, but between Beta and RC, we'll be putting a more intuitive solution in place on the V3 feed so that it will be easy to discern between listed and unlisted but more importantly, the resources exposed for package restore scenarios will include unlisted versions where resources exposed for search and dependency resolution simply won't include them. Then the client won't have to always have logic for checking fields on the package to determine if it's listed or not.

[troydai]

Fixed in 02d3bc9

[davidfowl]

@troydai marked bugs as "Done" when you fix them

[troydai]

Aye aye.