Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Re: Transient resolve and generated versiontypes

Kenneth Ölwing wrote:
From a purely technical standpoint, the crucial question is this:

Is the version type information for a given component important to know *before* or *after* mapping the component name to the info in the rmap?

I'm assuming/understanding that it is only important to know *after*. As you say, the code *must* know about it, otherwise the whole deck of cards fail, but the issue is still when it's needed.

Considering your comment about that it sounds like a good idea having version type information in the mp:entry element, it seems to me that the above assumption is correct. Continuing that thought: if it is ok for 'a Maven component' to get that information from the rmap, then logically, it must be ok for *any* component.

Can we agree on this as correct in principle?

From a pure resolver perspective and as things stand today, yes. I have an idea where the type can be made to influence the choice of provider (see "Extended proposal" below) that would change this.


Assuming yes, it's then a bit of a 'philosophical' issue perhaps; is it ok to separate the information about the version designator and the type for that designator into two separate locations?

Well, I don't see why not.
Aside from other reasons expressed here, I can see another fairly prominent reason not to separate the two. The coming CSPEC editor will need the version type in order to assist when version designators are entered (min must be <= max, names of enumerations must exists, type specific help, etc.).


The component name and version designator is a 'logical/soft' thing (perhaps, 'what I want'). The version type is 'physical/hard', just as in what repository/ies it can be found and how it should be accessed from there (i.e. perhaps 'how to turn what I want into reality). So a component query (or more specifically then, the component name and version designator in it) by itself is really of little use (in this particular respect) without an rmap that can turn the 'logical' component name into some hard facts. Therefore, it seems to me to be fairly reasonable to have the rmap carry the version type information as well.

Aren't we talking about different things here? The version instances of the designator are already 'logical/soft'. Their 'physical/hard' counterparts are the version selectors (tags, etc. created by the versionConverter of the SCM style repository readers). I'm talking about semantic differences in version instances. I.e. a major.minor.micro triplet has semantics that are very different from a timestamp or an enumeration of names. You are suggesting that different providers can interpret the version instances differently. I can't see that happening. The way I see it, instances of a designator are written to conform with one specific type.


If we think in terms of *human* roles (which is what I mean by the statement about '...all I know...') it might go something like this:

I, the 'plain Buckminster user' reads about a fabulous new component 'CoolThing' that I would like to try. I also read that it is now available as version '0.1beta-1'. So I cobble up a cquery for that combination of name/designator.

However, when trying that out Buckminster throws an error and complains that 'sorry, don't know anything about a CoolThing component'.

So, I turn to my friendly Buckminster-and-components savvy partner/consultant/whatever and point them to the CoolThing information. He/she examines it a bit deeper and soon figures out one of two things: 1) the CoolThing developers uses a version type known and implemented,
So, he tells you to do one of two things. a) Don't use a version designator at all or b) use a version designator that complies with the type used by the component. You need to do that in any case. At present, you also need to state what the actual type is.


or, 2) the version type as described has no version type handler implented, so one is created (that was quick :-). Finally, they enter the required information into the rmap I use, and get back to me.

In this case, surely he would inform you about the new version type. You need that information in order to express a range. Even if you don't need it right away, it's still a good idea to enter the type right next to your designator. That way, you don't need to go ask the next time.

Extended proposal:
Let each provider contain a table of known version types. Let repositories like Maven use this table when it generates transitive dependencies (my original suggestion). Also, let this table act as a discriminator so that a provider only handles queries with a version type that conforms with one of its known types.

Regards,
Thomas Hallgren



Back to the top