On 08/07/2015 01:08 AM, Christophe Demarey wrote:
Le 6 août 2015 à 22:49, Dale Henrichs a écrit :
For the Metacello tests themselves, the version of Metacello under test is installed on
top of the version present in the image, using the "standard Metacello update
code" ... failures at this point indicate Metacello upgrade problems ... then the
unit tests are run ...
ok, I found hat is missing.
Metacello update through the BaselineOfMetacello works ... but the code used
for the bootsrap of Metacello in BuilderCI uses the
ConfigurationOfMetacelloPreview and load the stable version that is currently
1.0.0-beta.32.17.
The change I made to builderCI[1] involves skipping the bootstrap of
Metacello (via ConfigurationOfMetacelloPreview) completely. The
Metacello bootstrap was been skipped for Pharo3.0 and Pharo4.0 and we
just missed that detail when adding Pharo5.0.
[1]
https://github.com/dalehenrich/builderCI/commit/0394467e5d13c7e99500fd30175a1210225f71ac
I think when there is already a version of Metacello able to load through the
baseline, builderCi should use the Baseline to update Metacello.
WDYT?
builderCI only ensures that there is a Metacello available, I don't
think that it should upgrade Metacello ...
I use builderCI to test the upgrade/update of Metacello to a new version
so to have builderCI automatically update would defeat the purpose and
mask issues.
Also if there are issues in the shipped version of Metacello that show
up when loading a particular project, then those issues should be
revealed, since the standard workflow for loading into an image should
not include lading the latest Metacello first...
If a project chooses to test with the latest version of Metacello
(something I often do for GemStone tests) then the project itself should
do the upgrade ...
Dale
