Releases should have many artifacts

[ezekg]

Releases should also not have a platform, filetype or filename, etc. These should all be attributes on the artifacts. A release should be a way to group many artifacts together around a specific version tag.

This would reduce a lot of complexity around upgrades. An upgrade could be requested by version only, and the correct artifact could be selected from there, e.g. by platform and filetype.

GET /v2/products/cli/releases/0.9.3/upgrade => /v2/products/cli/releases/1.0.0
GET /v2/products/cli/releases/latest => /v2/products/cli/releases/1.0.0
GET /v2/products/cli/releases/1.0.0/file.tar.gz

[ezekg]

Should v2 of the API drop JSON API compliance? Would make SDKs so much easier…

Also, we could have the upgrade endpoint be Squirrel-compatible.

[ezekg]

Are we able to do this while maintaining backwards compatibility?

[ezekg]

https://stripe.com/blog/api-versioning

[ezekg]

Move release attributes over to the artifacts model, and update the release serializer to pull from there instead for older API versions.

[ezekg]

Releases and artifacts should always be scoped by product.

[ezekg]

Add link to a hosted "download page" where an account can generate a download link for a release, which leads to a download page where the user can select the appropriate artifact to download. E.g.

{
  "links": {
    "download": "https://dl.keygen.sh/foo/bar/1.0.0"
  }
}

“Powered by Keygen.”

[ezekg]

Also, we could make these new endpoints v1 and keep the current endpoints as-is for backwards compatibility…

[ezekg]

To facilitate this move, we can start populating an artifact's platform/version/filetype/filename from the release, and pulling that into the release from the artifact (for backwards compatibility).

Then we could migrate to a release has-many artifacts relationship. Finally, we can deprecate the singular resources, and deprecate the release platform/version/filetype/filename attributes.

[ezekg]

For the current endpoints, we should use artifacts.sole to assert there is only 1 artifact when using the singular endpoints. Similarly, once a release has defined a platform or file{type,name,size} then it can only have a single artifact. Use redirects to point to the correct endpoint?

[ezekg]

Use the top-level artifacts relationship for creating multiple artifacts per-release? E.g.

POST /v1/accounts/:account/artifacts

[ezekg]

You should not be able to re-upload (replace) an artifact. Artifact should be deleted and re-uploaded. This will prevent the artifact's etag, content_type and content_length becoming out of date.

Edit: or we could simply clear these on re-upload.

Edit: the upload URL is only available on create, so this kind of solves itself.

[ezekg]

Moved to #627 (comment)

[ezekg]

Moved to #627 (comment)

[ezekg]

May be a good time to introduce engines #493. Engines could require a specific artifact structure to become available, e.g. for Rubygems, it'd need an artifact structure like this:

gems/hello-1.0.0.gem
latest_specs.4.8
latest_specs.4.8.gz
prerelease_specs.4.8
prerelease_specs.4.8.gz
quick/Marshal.4.8/hello-1.0.0.gemspec.rz
specs.4.8
specs.4.8.gz