Description
Actually the spec, in the discovery section, doesn't specify that, if no version is provided, it'll do discovery providing a default version as "latest". But the appc/spec code does this.
This is used for implementing the "latest" pattern. So someone could just define a single template like https://{name}-{version}.{ext}
and, if an user just requires "myaci" it will use:
https://myaci-latest.aci
I have some thoughts on pros and cons of this approach:
- It's handy since with an unique template, a server can implement "latest" just providing an url that can be a symlink/redirect to the real latest aci).
- it's different from the
noarch
approach. Here if someone wants anoarch
aci it should provide multiple templates in this order:
"https://{name}-{version}-{os}-{arch}.{ext}"
"https://{name}-{version}.{ext}"
on discovery, not providing os
and arch
, the first template will fail to render, and the second will render and be used.
Using the noarch
approach, the latest
pattern can be implemented with another template:
"https://{name}-{version}-{os}-{arch}.{ext}"
"https://{name}-{os}-{arch}.{ext}"
or
"https://{name}-{version}-{os}-{arch}.{ext}"
"https://{name}-latest-{os}-{arch}.{ext}"
So I have two proposal:
- Define in the SPEC the current behavior. No impact on actual server implementations but will keep actual confusion like in Clarify how to run/fetch the latest ACI rkt/rkt#2305
- Remove from the appc/spec code the defaulting of version to "latest" if not provided. This will impact current implementation since many expect to abtain the "latest" aci with just one template, but it's probably cleaner.
Before opening a PRs on first or second behavior I'd like to ear your thoughts.