Pin mongotalk to specific version instead of loading master about voyage HOT 10 CLOSED

I'm totally fine with it if it is an option;)

from voyage.

@noha, I think that makes sense ... you might use tag pattern matching to allow for bugfixes without having to re-release the configuration and if the master branch has progressed to far, the later tags can be on a bugfix branch ...

from voyage.

Thanks for the tip. I tried to do but I don't have access rights to the mongotalk repository. @tinchodias Can we release mongotalk as 1.10.0? I tried pinning voyage to the old 1.9.5 version but there are classes missing. So if there are no objections it would be best to release mongotalk 1.10.0 and pin voyage to it

from voyage.

So, it is done. Pull request #64 includes the change

from voyage.

@dalehenrich I tried your advize but it does not work. Using a ? in a version number let pharo3 and pharo4 on travis fail. So I guess the metacello in there is too old. I'm not sure if we have to wait until we retire the old versions or if there is something better

from voyage.

We decided to use a tag scheme to support the same thing. 1.10.0 is a version tag fixed at its commit. There is a tag 1.10 which is moves up in all 1.10.* versions. So voyage's baseline pins mongotalk to 1.10 which includes all the bug fixes in 1.10.*

from voyage.

hmmm. sounds like a Metacello or SmalltalkCI bug ...The metacello tests pass on pharo-3.0 and pharo-4.0 but then they also load the latest version of Metacello .. I think I'll submit a bug to SmalltalkCI, since I think it should be an option to update Metacallo to the latest version when running travis tests ... since there will always be the possibility that a particular Metacello bugfixis needed to be able load a project ...

from voyage.

I think all images should stay plain vanilla because the projects should be loadable in a fresh image without preparation.

from voyage.

I agree 100%, but when a project requires the latest version of Metacello, then you need a way to force Metacello to be updated ... if you feel that this shouldn't be an option, then please comment on the issue hpi-swa/smalltalkCI#197 and take part in the discussion there ...

In your particular case you chose a solution that does not require the latest version of Metacello and that is and always should be your choice, but projects that are choosing to go Metadataless should not be forced into ugly hacks just because they a) want to take advantage of a recent feature/bugfix in Metacello and b) want to ensure that their project runs cleanly on a given platform that may not come with the needed feature installed by default ...

from voyage.

BTW, with this option it would be possible to run tests against vanilla images (and expect failures) as well as run again images with the latest Metacello version installed (and expect success) ...

from voyage.