On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs <[email protected]> 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 >> > >
