On 12/18/2012 06:53 PM, [hidden email] wrote:
> Paul, > > #latestVersion should not be used anymore. > > You should be using the symbolic version #stable and control the version > that gets loaded on a platform by platform basis by specifying which > version is the #stable version... > > Dale Hi Dale, I agree with you that only #stable or a specfic version # should be used in a config. I think this was a case of me doing a bad job explaining the problem. If (using the version of the ConfigurationOfSeaside30 that has nested versions for Seaside 3.1 blessed as #development in Pharo 1.4) I doIt: (Smalltalk at: #ConfigurationOfSeaside30) load. Nothing happens because #load was looking up the #latestVersion and finding that the 3.1.0-gemstone version was the latest version. Then loading nothing. I would expect 3.0.7 to load. All the other 3.1.0- versions did not get found because they are all marked #development and excluded. #load (really #latestVersion) gets tripped up by the 3.1.0-gemstone version because that version has no spec calculated for it, and so the defaultBlessing of #release is used. I'm not sure its relevant considering the new scripting API but I'm bringing this to your attention because I expect that other configs may eventually exist that define different nested #development versions for both Pharo and Gemstone, and in those configs the idioms: ConfigurationOfXXXXX load (Smalltalk at: #ConfigurationOfXXXXX) load. won't work. Also - how dumb of me to not think of using Metacello to load an updated version of Metacello. jeez. my bad. Thanks for the reminder Paul |
Paul,
I guess I'm still missing something :) I suppose I need to see a stack to understand where #latestVersion is being called ... If it is being called directly from the class-side #load method, then the class-side #load method should be changed to use the #stable version ... One of the reasons I would like the Metacello Scripting API adopted is that whole set of adhoc class-side messages should go away ... with the scripting api, you don't directly manipulate the configuration classes... Dale ----- Original Message ----- | From: "Paul DeBruicker" <[hidden email]> | To: [hidden email] | Sent: Wednesday, December 19, 2012 8:37:38 AM | Subject: Re: [Metacello] Digest for [hidden email] - 2 Messages in 2 Topics | | On 12/18/2012 06:53 PM, [hidden email] wrote: | > Paul, | > | > #latestVersion should not be used anymore. | > | > You should be using the symbolic version #stable and control the | > version | > that gets loaded on a platform by platform basis by specifying | > which | > version is the #stable version... | > | > Dale | | | Hi Dale, | | I agree with you that only #stable or a specfic version # should be | used | in a config. I think this was a case of me doing a bad job | explaining | the problem. If (using the version of the ConfigurationOfSeaside30 | that | has nested versions for Seaside 3.1 blessed as #development in Pharo | 1.4) I doIt: | | (Smalltalk at: #ConfigurationOfSeaside30) load. | | | Nothing happens because #load was looking up the #latestVersion and | finding that the 3.1.0-gemstone version was the latest version. Then | loading nothing. I would expect 3.0.7 to load. All the other 3.1.0- | versions did not get found because they are all marked #development | and | excluded. #load (really #latestVersion) gets tripped up by the | 3.1.0-gemstone version because that version has no spec calculated | for | it, and so the defaultBlessing of #release is used. | | I'm not sure its relevant considering the new scripting API but I'm | bringing this to your attention because I expect that other configs | may | eventually exist that define different nested #development versions | for | both Pharo and Gemstone, and in those configs the idioms: | | ConfigurationOfXXXXX load | (Smalltalk at: #ConfigurationOfXXXXX) load. | | won't work. | | | Also - how dumb of me to not think of using Metacello to load an | updated | version of Metacello. jeez. my bad. | | | Thanks for the reminder | | | Paul | | |
Free forum by Nabble | Edit this page |