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
