Mariano, I think that #linear is the best default loadType...#atomic should only be used when it is really needed...
I think that for 1.1 new versions of "all of the configs" will need to be done eventually since they need to load into a 1.1 Pharo Core independently without requiring one to disable the deprecated warning... Since 1.1 is still unstable, it might make sense to wait until _all_ of the issues get resolved so we don't end up spinning multiple versions for 1.1 compatibility reasons... You could put a preload doit that disables deprecation warnings (if they are enabled) and a postload doit that reenables deprecation warnings at the end of the load .... this would only be a temporary measure until 1.1 stabilizes... With my short experience using 1.1 I cannot imagine that anyone would _enable_ deprecation warnings and expect anything to work without lots and lots and lots of proceeds:) Dale ----- "Mariano Martinez Peck" <[email protected]> wrote: | On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs | <[email protected]>wrote: | | > | > ----- "Mariano Martinez Peck" <[email protected]> wrote: | > | > | > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and | '1.1 | > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which | > | means that | > | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That | was | > | enough to | > | > solve this particular problem, but in an Inspector, you can | dive | > | into the | > | > directives themselves and actually get to the MetacelloSpec that | was | > | used to | > | > create the directive... | > | > | > | > | > | > | > | Here is what I don't understand. If you have that directive, and | you | > | have | > | ALL that information, can't you guess that if you need to load the | N | > | version | > | of a package and then the version M, where M > N, then you can | skip to | > | load | > | N and just load M directly ? | > | | > | In this example, can you DO NOT load OmniBrowser-lr.458 as you | know | > | that | > | after you will load OmniBrowser-lr.469 ? | > | Or maybe directly about conf: Do not load 1.1 | > | [ConfigurationOfOmniBrowser] if you know that then you will need | to | > | load | > | 1.1.3 [ConfigurationOfOmniBrowser] | > | > Mariano, | > | > If you were using #atomic loads then what you are suggesting would | happen | > ... Metacello would recognize that OmniBrowser-lr.469 was later and | would | > use that instead of the older mcz file. | > | > With #linear loads it isn't necessarily safe to substitute a newer | version | > of an mcz file earlier into the load sequence, because the newer | version may | > have dependencies that wouldn't necessarily be satisfied this early | in the | > load sequence...The only safe way is to explicitly move the project | earlier | > in the sequence. | > | > | Ahhhh those ones ;) Now is much clear. Thanks Dale. I forgot sbout | those | friends. Now I wonder.... if we select #linear is cool because all | the | packages will be loaded and initialized one after one. But we usually | would | need to update a lot of configurations to load ONLY the last version | in a | conflic. | On the other hand, if we use #atomic most of the times the newests | verions | will ONLY be loaded automatically, but we may have a problem as all | the | postDoIts are done all together at the end. | | So...which one do you think is the best approach for | ConfogurationOfPharo | ? I guess linear and update the others confs....what do you think ? | | cheers | | mariano | | | | | | > Moving the specification of OmniBrowser before the spec for | > AutomaticMethodCategorizer does result in the correct mcz file for | > OB-Standard to be loaded, however, other issues are exposed: | > | > SHOUT uses the deprecated registerMenu API | > Refactoring Browser needs to be moved earlier to avoid double | > loading. I didn't notice any ill effects of loading earlier | version of | > Refactoring Browser. | > Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory | not | > understood | > | > Perhaps the MNU is due to the fact that I haven't updated | > PharoCore-1.1-11326-UNSTABLE. | > | > My tests to this point were done with Metacello 1.0-beta.26.1 (in | > development) to eliminate any (known) Metacello bugs from the | equation. | > | > At this point I don't think 1.0-beta.26.1 is needed, but I will run | an | > additional test and let you know... | > | > Dale | > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
