2017-04-25 16:11 GMT+02:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:

[ Shortened for brevity ... ]��


Hum. I'm not trying to determine a version for the configurations present in the image... and #primeRegistryFromImage seems to, and then I seem to get errors because it selects a wrong version (at least I got an error doing that with ConfigurationOfEpicea, set at version 7.8.p4 where it should be version 8.1.3, and Metacello fails with a version not found).

I'll look a bit deeper to see what is happening and how to reproduce it.
It is very�� likely that you are running into the very type of bug that caused me to go with the Metacello registry in the first place ... It can be impossible for Metacello to guess the correct version of a loaded configuration ... I'm not sure it is worth much effort to try to characterize the problem ... better would be for Pharo to use "Metacello new" to build the image, so that the loaded versions are registered in the first place ...

Of course...

Now, I just compute the closure of all the configuration version specs over the set of packages present in the image, by name. If a package name is present in one of the version specs, then it is considered as part of the project.
��

If you insist on looking deeper:) a common cause of wrong guesses is that the configuration specifies a project version dependency or a version of package that is later than the versions actually loaded in the image --- this can happen when only a partial load of the configuration is done where those projects or packages are not actually loaded by the configuration itself --- without the actual registration information from the load, Metacello looks at the loaded projects/packages and tries to match it with a version of the configuration and this "false" dependency information causes Metacello to look for an earlier version that matches ...

Yes, this is the reason. In the case of Epicea in the latest image, the last version is 8.1.3, but ConfigurationOfEpicea>>#currentVersion returns 7.8p4.

7.8p4 is the highest version for which there is a dependency on the STON project, dependency which is respected in the image (version requested is 0.17, version present is 0.23). 7.8p4 and all higher versions also have a dependency on Smark, which isn't loaded.

Would that mean that:
- If one of the project in requirements is present in the image, then the version is considered current (here, for 7.8p4, Ston is present, Smark is not) if, for the packages of the project, all are present with versions higher than the current configuration version spec?
- If none of the projects in requirements are present in the image, then the version is not considered current (in 8.1.3, Smark is not present but I see no dependency on Ston[*]) ?

I have a feeling this is a strange result, and I'd prefer 8.1.3 to have the same validity as 7.8p4.

Is this MetacelloProject>>#currentVersion used to determine if a project should be upgraded?

Another question, related to the original topic: if the current configurations in the image are in this state, is it a good idea to leave them in? Would it have a chance of triggering incorrect updates or suspicious errors[**] if we start using them to load Metacello projects that depends on them?

Thierry

[*] The dependency on Ston is removed starting version 7.8p5

[**] for example, a project requiring Epicea >= 8.0

��


Dale