search

krfkeith / metacello

Automatically exported from code.google.com/p/metacello
0 stars 0 forks source link

Project reference causes OLDER version to be loaded #141

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
To reproduce:

  Pharo1.2.1-12345
  ConfigurationOfSeaside30 (dkh.316) 

  Metacello 1.0-beta.28.3.1

Evaluate the following expression:

    (ConfigurationOfSeaside30 project version: '3.0.5') record.

and note that OmniBrowser 1.2.3 is loaded:

        linear load : 1.2.3 [ConfigurationOfOmniBrowser]
            load : OmniBrowser-lr.503
            load : OB-Morphic-GuillermoPolito.153
            load : OB-Standard-GuillermoPolito.529

even though the current version of OmniBrowser is 1.2.4. 

This is not correct...

While I'm not (yet) sure why this is happening it should be noted that 
#currentVersion answers nil when sent from within 
MetacelloMCProjectSpec>>determineCurrentVersionForLoad...none of the version 
blocks fire ... 

With Metacello 1.0-beta.29 loaded, you get the correct behavior (i.e., 1.2.4 is 
not overridden).

I need to have a test case for this ... the one observation I have right now is 
that version 1.7 of the Refactoring Browseris loaded in the image and 1.7 is 
GREATER than any of the specifications for RFB in the 
configurationOfOmniBrowser (ConfigurationOfOmniBrowser (MarcusDenker.113)). All 
of the other packages and projects are exactly to spec, so the RFB version must 
trigger the failure ...

Original issue reported on code.google.com by henrichs...@gmail.com on 2 Jun 2011 at 3:06

GoogleCodeExporter commented 9 years ago 
In Issue 118, I changed the way that the currentVersionInfo: was calculated for 
#record (which may or may not be directly related). 

Prior to the fix for Issue 118, record was ignoring the packages that were 
loaded into the image when calculating what packages would be loaded by a 
project ... 

The packages that #record claim would be loaded are actually loaded during the 
#load, so it really seems that this could be related ... Unfortunately I don't 
think the MetacelloNullRecordingMCSpecLoader (the loader used during record) is 
actually used during the load ... The MetacelloNullRecordingMCSpecLoader should 
only be used for record, and this is where the change in behavior is evident...

Original comment by henrichs...@gmail.com on 3 Jun 2011 at 5:51

GoogleCodeExporter commented 9 years ago 
This is simply a #record issue and is fixed by along with Issue 118....but with 
Metacello 1.0-beta.29 I get a failure to load Seaside3.0 and _that_ is a 
consequence of Pharo Issue 4337 
(http://code.google.com/p/pharo/issues/detail?id=4337)

Original comment by henrichs...@gmail.com on 3 Jun 2011 at 9:00