Metacello and #stable

> Hi,
>
> If I specify a stable version for a platform (spec for: #'pharo3.x'
> version: '3.0.6'.), shouldn't Metacello load that version?
>
> Concrete use-case: loading ConfigurationOfMoose in Pharo 3
> - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3
> - ConfigurationOfMoose version 5.0 loads  ConfigurationOfGlamour #stable
> - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3
> (spec for: #'pharo3.x' version: '3.0.6')
>
> Loading ConfigurationOfMoose [1] in  Pharo 3 loads version 3.0.9
> for ConfigurationOfGlamour.
> Updating Monticello leads to the same result.
>
> Did I misunderstood something about how monticello works?
> Any idea how to debug this?
>
> Cheers,
> Andrei
>
> [1] (ConfigurationOfMoose project version: #'stable') record loadDirective
>

> Andrei,
>
> 1) The old configuration load api is non-deterministic, especially when used
> with large configurations, Metacello will not downgrade a package, so if
> (using the old api) Metacello decides that a newer version of a
> configuration is present, then it will use the newer (and possibly incorrect
> version). Keep in mind that pre-loaded packages in Pharo can influence this
> non-deterministic calculation.
>
> I don't know for certain that using the old API is the culprit. The only way
> for me to understand where the issue might lie is for me to look at the
> Transcript output of a load.
>
> 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not
> actively tested then they are likely to quit working over time and I'd guess
> this is the case for Pharo3.0 and Moose.
>
> 3) using #stable is a very inaccurate way of specifying a symbolic version.
> The Seaside folks have started using version-based symbolic versions like:
> #'release3', #'release3.1', #'release3.2' a while ago and I think this is a
> very good way to leverage symbolic versions ... #stable can be changed and
> in the mind of the developer #stable is now version 4.0.0, while a number of
> older configurations will consider #stable to be version 3.0.0 ... it
> doesn't take long the #stable version universe to be completely confused ...

>
> While I suspect that the current #stable version of Moose does not run on
> Pharo3.0, if version-based symbolic versions had been used back then the
> configurations would likely still be usable ...
>
> Again, I am just guessing ... analysis of the Transcript output would give
> me better clues ...
>
> Using the new Metacello scripting API:
>
>     Metacello new
>       configuration: 'Moose';
>       version: #stable;
>       repository: '???';
>       load
>
> does a load without without calculating the #currentVersion and should be
> deterministic with respect to loaded versions ... this only addresses the
> first point above. If points 2 or 3 are involved, then it may be more
> difficult to solve the problem ...
>
> BTW, sorry for taking so long to get back to you ... in the last month I've
> taken a long overdue vacation (and did not even open my laptop:) and have
> been working exclusively on GemStone 3.3 ... I'm nearly finished with my
> main commitments for GemStone 3.3 and as I come up for air, I'm working off
> my email backlog:)
>
> Dale
>
> On 5/18/15 5:56 AM, Andrei Chis wrote:
>>
>> Hi,
>>
>> If I specify a stable version for a platform (spec for: #'pharo3.x'
>> version: '3.0.6'.), shouldn't Metacello load that version?
>>
>> Concrete use-case: loading ConfigurationOfMoose in Pharo 3
>> - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3
>> - ConfigurationOfMoose version 5.0 loads  ConfigurationOfGlamour #stable
>> - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3
>> (spec for: #'pharo3.x' version: '3.0.6')
>>
>> Loading ConfigurationOfMoose [1] in  Pharo 3 loads version 3.0.9 for
>> ConfigurationOfGlamour.
>> Updating Monticello leads to the same result.
>>
>> Did I misunderstood something about how monticello works?
>> Any idea how to debug this?
>>
>> Cheers,
>> Andrei
>>
>> [1] (ConfigurationOfMoose project version: #'stable') record loadDirective
>>
>
>

> On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs
> <[hidden email]> wrote:
>> Andrei,
>>
>> 1) The old configuration load api is non-deterministic, especially when used
>> with large configurations, Metacello will not downgrade a package, so if
>> (using the old api) Metacello decides that a newer version of a
>> configuration is present, then it will use the newer (and possibly incorrect
>> version). Keep in mind that pre-loaded packages in Pharo can influence this
>> non-deterministic calculation.
>>
>> I don't know for certain that using the old API is the culprit. The only way
>> for me to understand where the issue might lie is for me to look at the
>> Transcript output of a load.
>>
>> 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not
>> actively tested then they are likely to quit working over time and I'd guess
>> this is the case for Pharo3.0 and Moose.
>>
>> 3) using #stable is a very inaccurate way of specifying a symbolic version.
>> The Seaside folks have started using version-based symbolic versions like:
>> #'release3', #'release3.1', #'release3.2' a while ago and I think this is a
>> very good way to leverage symbolic versions ... #stable can be changed and
>> in the mind of the developer #stable is now version 4.0.0, while a number of
>> older configurations will consider #stable to be version 3.0.0 ... it
>> doesn't take long the #stable version universe to be completely confused ...
> For a Configuration newbie it may seem intuitive for a Configuration
> to dependend on other Configuration's #stable without realising the
> hole they are digging.  You could say its easy to shoot yourself in
> the foot with #stable?  So maybe #stable only makes sense as a
> *convenience* for interactive users at the "command line."  It might
> be reasonable for the system to block use of #stable within a
> Configuration (with a deprecation warning and bypass method like
> #allowNestedStable)
> cheers -ben
>
>> While I suspect that the current #stable version of Moose does not run on
>> Pharo3.0, if version-based symbolic versions had been used back then the
>> configurations would likely still be usable ...
>>
>> Again, I am just guessing ... analysis of the Transcript output would give
>> me better clues ...
>>
>> Using the new Metacello scripting API:
>>
>>      Metacello new
>>        configuration: 'Moose';
>>        version: #stable;
>>        repository: '???';
>>        load
>>
>> does a load without without calculating the #currentVersion and should be
>> deterministic with respect to loaded versions ... this only addresses the
>> first point above. If points 2 or 3 are involved, then it may be more
>> difficult to solve the problem ...
>>
>> BTW, sorry for taking so long to get back to you ... in the last month I've
>> taken a long overdue vacation (and did not even open my laptop:) and have
>> been working exclusively on GemStone 3.3 ... I'm nearly finished with my
>> main commitments for GemStone 3.3 and as I come up for air, I'm working off
>> my email backlog:)
>>
>> Dale
>>
>> On 5/18/15 5:56 AM, Andrei Chis wrote:
>>> Hi,
>>>
>>> If I specify a stable version for a platform (spec for: #'pharo3.x'
>>> version: '3.0.6'.), shouldn't Metacello load that version?
>>>
>>> Concrete use-case: loading ConfigurationOfMoose in Pharo 3
>>> - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3
>>> - ConfigurationOfMoose version 5.0 loads  ConfigurationOfGlamour #stable
>>> - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3
>>> (spec for: #'pharo3.x' version: '3.0.6')
>>>
>>> Loading ConfigurationOfMoose [1] in  Pharo 3 loads version 3.0.9 for
>>> ConfigurationOfGlamour.
>>> Updating Monticello leads to the same result.
>>>
>>> Did I misunderstood something about how monticello works?
>>> Any idea how to debug this?
>>>
>>> Cheers,
>>> Andrei
>>>
>>> [1] (ConfigurationOfMoose project version: #'stable') record loadDirective
>>>
>>