About version ranges

I think metacello is great tool. In my work we are currently moving
little by little to use tools build around Pharo and away from Java
tools. We have used Maven quite extensively and it gives possibility
to define version ranges. Is this yet possible in metacello?

Currenlty I have one actual need for this feature. I have been very
slowly developing pooling library and pool for SqueakDBX connections.
I would like to create configuration wich would load the library but
there is no point to spesify exact version of Glorp/SqueakDBX it
requires. People who might want to use the library could have some
other version of SqueakDBX installed. If my configuration specifies
exact version of SqueakDBX it would force them to upgrade SqueakDBX.

If this kind of feature does not exists and sounds reasonable I could
try to implement it...

--
Panu

Panu,

Metacello doesn't quite have version ranges ... it is possible to supply a project specific operator for use in constraining a required version (all of the comparison operators are allowed) and by default it is #>=.

With the default operator you can specify a minimum version that is required for another project and Metacello will load the minimum required version if it is not already loaded into the image ... So I think you might be able to use this feature to get what you want without having to go all of the way to version ranges.

If we do need to go there now (I plan to eventually add version ranges ... along with unload) I would be interested in your ideas on ways to specify a version range and then I'd be willing to work with you on the implementation ... the fact that Metacello is already doing version comparisons should make it relatively straightforward to do ...

Dale

On Mar 23, 2011, at 12:32 PM, Panu Suominen wrote:

2011/3/23 Dale Henrichs <[hidden email]>:
> Metacello doesn't quite have version ranges ... it is possible to supply a project specific operator for use in constraining a required version (all of the comparison operators are allowed) and by default it is #>=.
> With the default operator you can specify a minimum version that is required for another project and Metacello will load the minimum required version if it is not already loaded into the image ... So I think you might be able to use this feature to get what you want without having to go all of the way to version ranges.

This basically solves my problem. However in long run it might become
necessary to set upper bound to some dependency which is no-longer
suitable. It would kinda break the idea not to change for old
versions. But adding this information could make it clear to the user
that one can not load the project because of too new dependency is
found.

> If we do need to go there now (I plan to eventually add version ranges ... along with unload) I would be interested in your ideas on ways to specify a version range and then I'd be willing to work with you on the implementation ... the fact that Metacello is already doing version comparisons should make it relatively straightforward to do ...

I tought simply adding something like
#versionFrom:,#versionAfter:,#versionTo:,#versionBefore: -could be
added to API:
spec versionFrom:'1.2.3'; versionTo: '4.5.6
spec versionAfter:'1.2.3'; versionBefore: '4.5.6

I looked the code a little and it seems that implementing this would
not be such a hard work. However I did not have time to see if there
is some mechanism to check dependency conflicts and suchs. In simple
cases it would be just summing up ranges for same project. For example
'1.2' - '1.6' and '1.5'-'1.7' should probably result loading '1.6'
which is latest version in ranges. But this could lead to cases where
loading is not possible. If on dependency to be in range '1.1' - '1.2'
and there is also a requirement for '1.3' - '1.4'. Also it might be
good thing to see what other versions loaded to the image require.
With this kind of checking one could check not to broke preloaded
packages. But this might be quite hard...

Yet I haven't used metacello so much that I could say how much value
these kind of changes would introduce. With packages that are actively
maintained and where no-one is interested in older versions ranges
would not make much difference.

--
Panu

On Mar 23, 2011, at 1:55 PM, Panu Suominen wrote:

Yes, I have found that for the most part having a minimum required version covers the bulk of the use cases ...

>
>> If we do need to go there now (I plan to eventually add version ranges ... along with unload) I would be interested in your ideas on ways to specify a version range and then I'd be willing to work with you on the implementation ... the fact that Metacello is already doing version comparisons should make it relatively straightforward to do ...
>
> I tought simply adding something like
> #versionFrom:,#versionAfter:,#versionTo:,#versionBefore: -could be
> added to API:
> spec versionFrom:'1.2.3'; versionTo: '4.5.6
> spec versionAfter:'1.2.3'; versionBefore: '4.5.6

This approach wouldn't be too bad ... I had been thinking about some kind of funky expression syntax, but simple messages make it much easier to deal with ...

Once we implement an upper limit, the load will be much harder, because we _will_ have cases where the load cannot be completed because one projects minimum version is greater than another projects maximum version ...  It's the main reason I haven't gone after this feature ...

With that said, the fact that the load goes through the fetch phase, we could easily find the conflict before any real loading had been done ...

>
> Yet I haven't used metacello so much that I could say how much value
> these kind of changes would introduce. With packages that are actively
> maintained and where no-one is interested in older versions ranges
> would not make much difference.

In the fullness of time, I think that version ranges are a required feature, but so far I think that we can wait until after 1.0 is out to tackle them.

Dale