On Tue, Feb 27, 2018 at 6:43 PM, Jason Greene <jason.greene@redhat.com> wrote:

On Feb 22, 2018, at 4:41 PM, Alexey Loubyansky <alexey.loubyansky@redhat.com> wrote:

 I could provide a default GAV coordinate resolver based on how we are used to define our GAVs and also let the user (project owner) provide a custom one.

Ideally the specification approach we decide on is consistent across the family and even the universe. It’s easier IMO to look at this from a user interaction perspective, and to consider which source of info is authoritative. 

For initial consumption there is two ways a user will specify what they initially want:

A) Give me the latest WildFly (latest on a given branch:classifer)

B) Give me exactly this version of WildFly (e.g. WildFly 12.0.0.Final)

As you mentioned earlier in the thread, even when A is used we need to store B so that the prov config is reproducible. Whats also interesting is that in most cases the user does not care what the policy details are for updating to the latest, they will happily accept the default, and really in that scenario the authoritative source is a registry artifact in  the maven repo, not necessarily whats in the provisioning file. The policy details also aren’t important for reproducibility, since the full version already gives you what you need. Where it would be important in the provisioning file is when the user has overridden the rules. As an example, just because a user installs 12.0.0.Beta1, doesn’t mean that from now on they always want betas. They might just want to try a particular beta, and then update back to the main stream. So to resolve the ambiguity, in any case other than the default, the user would have to specify the stream they are interested in.

What I want to achieve with this is make the initial choice of A) or B) not important in a sense that if the user chose to install the latest version, the provisioned installation will remain 100% reprodicible since the recorded state will include specific versions of the installed feature-packs.
And if the user choice B), i.e. to provision a specific version, then the usual update command would still work, because the family:branch:stream is a part of the coordinates of the initially chosen specific version.
The same applies to the dependencies of the explicitly installed feature-packs. The dependencies will always be of specific versions to guarantee the reproducibility of the release. But from their coordinates we can figure out the branch and the stream they originate from. And when executing update we can poll for dependency updates as well.
The user would be able to switch to a different stream of the same branch, that would have to be an explicit instruction though. I think the default stream should be final releases. If the user wants something else then it will need to be expressed explicitly.

Switching between branches of the same family could work too. I guess that would depend on a specific project and the compatibility between major version releases.
 
One other thing to keep in mind, from a usability perspective, is to be careful with using things that look like GAVs but aren’t GAVs

That's a good one, agreed.

Thanks,
Alexey
 

-Jason