Ok, i will follow the issue on github. Thanks!
2013/7/1 Dale K. Henrichs <dale.henri...@gemtalksystems.com> > Guido, > > I created a test case and it turns out that there _is_ a bug in the bypass > lock logic[1] . I'm going to push out a new version of the Metacello > Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue > #174 will _not_ be included in that release ... > > Dale > > [1] https://github.com/dalehenrich/metacello-work/issues/174 > > ------------------------------ > > *From: *"Guido Chari" <cha...@gmail.com> > *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> > *Sent: *Thursday, June 27, 2013 10:23:33 AM > *Subject: *Re: [Pharo-dev] Metacello doubt > > I'm in. > > > 2013/6/26 Dale K. Henrichs <dale.henri...@gemtalksystems.com> > >> >> >> ------------------------------ >> >> *From: *"Guido Chari" <cha...@gmail.com> >> *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> >> *Sent: *Wednesday, June 26, 2013 2:49:09 PM >> >> *Subject: *Re: [Pharo-dev] Metacello doubt >> >> I understood. Thanks for the answer Dale. The drawback in this case is to >> specify a particular dependency to AsmJit in my configuration. Also, >> perhaps is the right way since i realized i have a particular dependency on >> it. >> >> But this discussion makes me thing a little and so i have a new question. >> >> Form what I (mis) undestand from Metacello, when asking for a >> bleedingEdge version it loads only the baseline that specifies packages and >> then last version of every package specified there. >> >> As in the projects referenced on the baseline there is no need for >> specifying a version, and that's the case of nativeBoost configuration, >> wouldn't it be interesting to have some behavior (i mean i new method for >> loading like loadDeepSymbolic:) that not only load the symbolicVersion of >> the package asked, but also propagate that symbolicVersion (bleedingEdge in >> this case) to all the dependencies that don't specify a concrete version? >> >> Guido. >> >> Guido, >> >> With the Metacello Scripting API[1] I've taken a slightly different tack, >> but I think that it gets you to the same place. >> >> I am a big fan of deterministic loads, but I know that from a practical >> point of view developers need to have a certain amount of control over >> exactly what gets loaded into their DEVELOPMENT environments and they need >> to be able to exert this control without having to resort to editing >> configurations to match their specific requirements. >> >> I have accomplished this by arranging for a Notification to be signalled >> whenever a project is referenced during a load. The developer can use one >> or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their >> load scripts to exert fine control over what happens on a project by >> project basis ... >> >> For your specific use case, I would think that you would want to use the >> `lock` command[2] and specify that you want to `lock` the projects >> (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if >> I've got test cases for symbolic versions, but if you are seriously >> interested in taking the Scripting API for a spin, I'd be willing to write >> some additional tests using the #bleedingEdge symbolic version (if not >> already covered) and validate this use case... >> >> I am entering a phase where I will be doing some work on getting FileTree >> and Metacello up to snuff for Pharo3.0 so this would be a good time for me >> to add some test cases in anticipation of having some interested users ... >> >> I haven't released the Scripting API, because I need to have real users >> with real use cases take the API for a spin and validate the API. The >> Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I >> think the Scripting API is (or will be) available in Pharo3.0. >> >> I'm looking forward to getting feedback as to how the API stands up to >> real use ... >> >> So let me know if you are interested in being another Scripting API >> guinea pig:) >> >> Dale >> >> [1] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md >> [2] >> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking >> >> > >
