On Feb 27, 2011, at 11:56 PM, laurent laffont wrote:
Metacello always goes with the latest version (okay a project can change it's rule, but the default rule is >=).
On Mon, Feb 28, 2011 at 8:40 AM, Dale Henrichs <dhenrich@vmware.com<mailto:dhenrich@vmware.com>> wrote:
Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without ShoutWorkspace, which I think is correct ... so ProfStef is okay ...
BTW, validation doesn't check whether versions match or not ... if Shout had a symbolic version defined for Pharo1.2, then I would say that you should use #stable ... so that you can track the "approved version of shout for Pharo1.2", however if your project is tightly coupled to Shout then I would use a literal version number ...
OK. So now
(ConfigurationOfProfStef project version: '1.6') load.
will load Shout 1.2.2.
1/ if I have:
ConfigurationOfProfStef 1.6 -> Shout 1.3
ConfigurationOfPharo -> Shout 1.2, ��ProfStef 1.6
which Shout will be loaded then ?
So Shout 1.3 will be loaded ... it's one of the reasons that symbolic versions were added: so that projects that need to have Shout loaded can just specify #stable and they don't have to worry about which platform or which version of Pharo the project is being loaded into ... you'll get the "correct version" ...
If Shout can break your application, then you have a tight coupling to Shout and you need to worry about which version you are using ... Seaside3.0 and Grease are tightly coupled....
2/ if I have
ConfigurationOfProfStef 1.6 -> Shout #stable
and then a new #stable release of Shout 1.8 breaks compatibility with ProfStef. I suppose ��ConfigurationOfProfStef 1.6 ��won't work anymore ?
I don't the specifics of your implementation, but I assume that ProfStef just wants syntax highlighting for the workspaces then you have a loose coupling and useing #stable should work... in this case, if syntax highlighting breaks it isn't really ProfStef's fault ... more likely someone should _not_ have specified Shout 1.8 as stable:) ...
IN my documentation I have tried to say what I know to be true:) The exact usage model for symbolic versions hasn't become completely clear ... 2 months ago, I figured that symbolic versions should be used everywhere, but I have backed off that and recommend that symbolic versions be used in literal versions when there is a loose coupling between the projects.
PS: I've gone through all Metacello help included in Pharo 1.2 recently - very cool to have this. ��However I've just checked and it seems there's no explanation on dependency on symbolic versions.
In baseline versions, I recommend that you certainly use either #bleedingEdge for tightly coupled projects or #stable for loosely coupled projects that way you can limit the exposure you have when using baseline versions to load the latest versions of everything ... #stable will just get you the known working version ...
I've been threatening to write a post about that, but I am finding that I am buried with work,so the documentation suffers:)
Dale