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

[Thomas Hallgren <thomas@xxxxxxx>]

ken1 wrote:
> I'm feeling that it's upside down to set table etc on a provider - I
> still feel that it is a particular component that is associated with a
> particular version type. Again, this is assuming the version type is
> constant across all the places and in all forms that component can be
> found (I can't see that happening, but if it would, all these
> arguments go out the window of course).
>
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.

> So, in a cspec when you express a dependency you fundamentally express
> a query. Information about how the query should be resolved should not
> be part of the query. Somewhat reminiscent of that in an SQL query you
> don't really trouble yourself much with the exact datatypes of the
> fields you query for, that's the db engines problem.
>
You must know the type. Using strings, the expression '11' < '2' yields
true.

The SQL analogy to my argument is more that the query itself would
change since the layout of the involved table would be different.
Translated to SQL, the difference between version types could be
expressed like:

v.major = 1 AND v.minor = 2 AND v.micro > 3

versus

v.timestamp > '20060326 13:23:12'

versus

v.name IN ('alpha','beta','gamma')

i.e. totally different semantics.

> Consider that I have ten completely separate components in separate
> project. However, they all need a common component A (in various
> versions). Why should all ten detail how the version designator should
> be interpreted? That's just redundant. Just letting the component name
> be a key to a single instance of this type of information seems more
> correct and efficient to me... It's just a form of normalizing, no?
>
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?

> You claim that the editor may/will need the version type information.
> This is a valid point. In principle, it's arguably possible for the
> editor to do the same lookup in the rmap (or elsewhere, see below) and
> thus get the version type information it needs. Ok, maybe there are
> instances when you work with a cspec and don't yet have the
> rmap...fair enough, that would be a problem. Solve by 1) make sure
> there's an rmap first,
A CSPEC is no way connected to a specific RMAP. Are you suggesting that
it should be?


> or 2) ask the user to manually provide such information,
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.


> or 3) simply keep the version type info as is in the cspec, but come
> resolvement time, that information *must* be equal to what the rmap
> says (this would be sort of a compromise between having it in one or
> the other place).
>
This sounds similar to my "extended suggestion". Use the version type
both for parsing/validation and as a provider discriminator.

> 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?

- thomas