Re: [buckminster-dev] Re: Transient resolve and generated versiontypes

["ken1" <kenneth@xxxxxxxxx>]

> But it *does* happen. A component is periodically made available to a
> bigger audience as timestamped snapshots in a maven repo and finally
> released with a major.minor.micro triplet (in the same repo). Here's one
> example:
>
> http://www.ibiblio.org/maven/netbeans/jars/
>
> Using SVN or Perforce, the scenario can probably be complicated by a
> desire to use change-numbers for the internal organization.
>

As noted, if the assumption of a non-changing version type wasn't
true, much of my arguments come unglued...

I think this is the key problem. The version type ideally shouldn't
change. Components using versions with these characteristics ideally
needs to be assigned a single version type that understands all these
forms and thus can accurately relate them to one another. The
semantics must be defined in all cases (they are with OSGi for
example). Assume you have expressed a dependency with component name,
a version designator (simple 'minimum this') and a version type. That
is all dandy and works fine for, say, when all the versions are in
CVS. However, we allow the user to arbitrarily say...hmm, but I'm
satisfied with this in binary only. Now the resolvement ends up with
the maven provider rather than CVS. If the rules for the version type
changes completely, of what use is the version designator that worked
well for CVS?

Admittedly though, given the example you cite, having a version type
that with no 'extra' information can tell if cvslib-200310240100.jar
is lesser or greater than cvslib-3.6.jar is pretty much impossible...:-(

I believe I have a better understanding of the issue now and will come
back to a new discussion at the bottom.

> You must know the type. Using strings, the expression '11' < '2' yields
> true.

Of course the type must be known. It's 'just' a matter where it's
declared. What I've been advocating is not that the version type is
unknown, rather that it's better to store it once and look it up there
(keyed on component name) instead of many redundant times. Also, I
think it's relevant to come up with a declaration that is generally
applicable regardless if we're seeing a bona fide cspec generated from
a 'real cspec' file or a generated cspec generated from a POM.

But, parts of the argumentation becomes somewhat problematic in the
face of varying version types...

> All ten knows what version of A that they depend on. Most commonly,
> they'd know the minimum version. We also allow them to express what
> range of versions they can use. How can you express a minimum or a range
> of something you don't know the semantics of?

Again, I *do* know the semantics of it. I just don't think (well,
thought) it should be physically declared right next to the version
designator. And, considering the varying version types, this sort of
becomes even more true - when I edit my query I enter a version
designator, and then also enter a version type, it is only applicable
to one particular form and if the user makes selections that changes
the form it might throw out the version designator semantics too.

As it turns out, seems to me that it must be room for some form of
compromise here where actually both mechanisms are important. Maybe
this is what you've been advocating all along...

> A CSPEC is no way connected to a specific RMAP. Are you suggesting that
> it should be?

I'm suggesting, and wrote so earlier, that a cspec by itself is today
somewhat useless without an rmap. The component name must be mapped to
'something'. Today this is the rmap, and hence, the suggestion to
stuff more information there (one single place, no redundancy). If
we'd like more normalization, well, that was the reason for the
'cmap'. Just an example.

> And then forget it so that someone later can use different semantics
> then the ones that I intended when I created it? This is the part that I
> don't understand.

No, it still must be stored somewhere, where it can be looked up.
Preferrably as non-redundantly as possible.

> This sounds similar to my "extended suggestion". Use the version type
> both for parsing/validation and as a provider discriminator.

Right, perhaps we're (or I am) beginning to find the common ground...

>
>> Maybe the existing split is not rich enough...what about splitting the
>> rmap into more than one thing - perhaps a 'cmap', a component
>> map/database. Now, the query expresses 'what I want', the cmap
>> expresses 'what it is', the hard facts about the component (the
>> component name is the key), and the rmap expresses 'how to get it'.
>>
> The only time you'd need a richer split is if you for some reason decide
> to apply different version semantics to one and the same version. There
> is no reason for such a split as long as you don't do that. Can you see
> a use-case when this happens?

How do you come to the conclusion that this is the only reason? Read
the above again - three parts: what I want, what it is and how to get
it. Just normalized information to make things clearer. It's not
necessary; the rmap can be both the last parts.

====

So, if I understand your suggestion better now and then run with it a
bit, would we be able to come up with a way to conclusively declare
multiple version types for a given component, so that there is an
inherent order between them that clearly expresses lesser/greater
priority up and down the chain? I.e. a key desire is to get some form
of determinism here.

This does call for the cspec to indeed express the type of the
designator in the cspec. In the case of a generated cspec from POM
however, there simply is no such data, and that leads to having the
relevant data in the rmap somehow.

Ok, beginning on the level of a searchpath to a particular component:
here it is declared what the *main* version type of the component is.
Or perhaps better, here it is declared all the possible version types,
and the order is significant.

When you come in with a query, you always start out with known
name/designator/type, so the first step is simple. During resolvement
of that, the type however must exist in the list of allowed types for
the component. Based on other discriminators (and the type also, if I
understand you?), we may however end up with a provider which may
exhibit another version type (or several). How do we now translate a
designator intented for type A when we only have type B? There ought
to be a defined way to step up/down the priority ladder. Some type of
adapter extpoint that has the knowledge to properly translate, say
'foo-3.6, type A' to 'foo-20060720, type B' (i.e. the minimum version
that is closest to 3.6 is 20060720). If you have many possible version
type and you start with type A and need to get to type F, you have to
adapt A=>B, B=>C, C=>D, D=>E and finally E=>F...sounds complicated...:-)

Just loose thoughts...how do you address a provider that supports many
possible types, and when you enumerate a component and get all the
possibilities, how do you know where to start...hm, the original type,
or if not present in the list for this provider, the topmost (or
bottommost, depending on where the original fits in the scheme of
thinsg) version type in that list (and then adapt up or down...).

ken1