Add options for controlling version sort and constraints behaviour

[kmoe]

Consider the case in which the versions available are (in go-version sort order):

• v2.0.0-alpha1
• v2.0.0-beta1
• v2.0.0-beta1+ent
• v2.0.0
• v2.0.0+ent
• v2.1.0-rc1

Calling releases.LatestVersion with a constraint of >1.0.0 will lead to v2.0.0+ent being installed.

This is produced by the following go-version phenomena, each of which may be something the user might want to control:

• prerelease versions cannot match constraints without a prerelease
• two versions that differ only in metadata are considered equal
• x.y.z+meta is greater than x.y.z.

We might want to provide some boolean options such as IncludePrereleases, IgnoreReleasesWithMetadata, etc. These could be a property of the Source or of an extended Constraints type.

Sensible defaults will be important here. I think the v2.0.0+ent result is a bit unexpected and that releases with metadata should be excluded by default, but more research is needed.

[radeksimko]

I agree that the current state is not ideal/sufficient and also agree that we should add a bool toggle to opt-in to prereleases. 👍🏻

Sensible defaults will be important here. I think the v2.0.0+ent result is a bit unexpected and that releases with metadata should be excluded by default

Totally agree with you here - I didn't even realize go-version has this side effect.

AFAICT we only use metadata to identify enterprise products (via ent), and I don't think that anyone would ever want to mix up OSS and Enterprise (accidentally install one instead of the other).

i.e. if someone needs to run tests against latest Consul Enterprise, then they'll want to ignore non-enterprise releases, similarly if someone runs tests against OSS releases they will want to ignore Enterprise.

With that in mind I'd propose Metadata string which will have to exactly match any metadata. It can default to an empty string - i.e. releases with metadata are ignored by default - and allows users to opt-in by setting Metadata to ent to only list enterprise releases + still leaves room for other kinds of metadata.

It may be worth double checking if anyone planned any other use cases for metadata and consider Enterprise bool as an alternative option. I see this mostly as hc-install implementation detail though. go-version should IMO just do exact-matching of a string and not care about meaning of metadata.

[shore]

There are also multiple types of enterprise release (e.g., https://releases.hashicorp.com/vault/1.7.3+ent.hsm/). If we want automated parsing of fields within the metadata, maybe we should include that in ENGSRV-069, even if mainly as a placeholder, like "enterprise builds must have ent at the beginning of the metadatafield; if there's additional metadata, it must be in separate, dot-separated subfields".

[radeksimko]

@shore Thank you for the note - that's a useful example. I agree that some standardization of the metadata field would be useful.

I don't have too strong opinion on this, but I think we can still have Enterprise bool flag which would only match https://releases.hashicorp.com/vault/1.7.3+ent/ but not https://releases.hashicorp.com/vault/1.7.3+ent.hsm/ That way most enterprise products can be installed easily (without digging too deep into docs) and we could have EnterpriseMeta string for that edge case you illustrated, which just appends . and arbitrary string.

[radeksimko]

For posterity: After discussing this with @mmcquillan and @kmoe we decided to drop support for downloading/installing all Enterprise releases initially, as a precaution related to licensing and some upcoming work in that area. We can however revisit that decision later - it's always easier to add than remove things! 😄

#16 implements that decision

[mikemorris]

Just wanted to bump this and note that we are going to have a need in the Consul API Gateway project of downloading a Consul Enterprise binary to test against, and would love the see the scope of hc-install expanded to include this.