Package Collection Format

[yim_lee]

@mattt, in response to your questions:

Version-specific manifest/tag selection was definitely brought up, but we haven't decided what we want to do yet. It's something we will revisit before shipping the feature.

@mattt

What do you think about representing Swift support as a cross-product / matrix of verifiedSwiftVersions and verifiedPlatforms ?

Are you suggesting something like this?

{
  "verifiedSwiftVersions": [
    {
      "name": "5.2",
      "verifiedPlatforms": [{ "name": "macOS" }, { "name": "Linux" }]
    },
    {
      "name": "5.3",
      "verifiedPlatforms": [...]
    }
  ]
}

I think it's reasonable, though I modeled it after how swiftpackageindex.com presents such data (example) and would be curious to see @daveverwer/@finestructure's opinion on this.

@mattt

Should there be a way to communicate compatibility exceptions somehow?

I think this kind of information should be part of the package's README or release notes. In other words, it is the package developers' rather than collection publishers' responsibility to explain why a language version and/or platform is not supported.

@mattt

Could you speak more to the rationale behind the revision value in the JSON payload? Is the intention for that to be used for cache invalidation?

It's mainly a way for collection publishers/users to reference different versions of a collection. We don't intend to interpret it in any meaningful way.