Christophe I agree with you
> As a general purpose reflexion on dependencies conventions, I would say:
> If you are in development mode, it makes sense to rely on latest versions of
> dependencies (bleeding edge) to be able to detect integration problems as
> soon as possible.
> If you are in a release mode, you should ensure that your code can run at
> least on fixed dependencies versions (at the best, specify a range of
> versions you can use with possibly no upper limit if your dependencies ensure
> backward compatibility). You need reproducible loading of your tool/lib.
> in my opinion, you shouldn't use #stable for release version as the only
> thing it ensure (if well tested) is that you will not have a broken version
> of the dependency. The stable version of your dependency will evolve and then
> the configuration of your release too. At a time, your version will not be
> usable at all because of that.
Because even if you milestone against a major version,
what you mean is that the package may change (and still
work on 20 for example, but be incompatible with your software).
I will write something in the metacello chapter and see what I
wrote on symbolic version.
> so I would specify a dependency with a versionString for release versions of
> your lib/tool. It ensures a minimum version.
So I wonder when we should use stable.
Versionner will solve all these points for us :)
Stef
>
> Regards,
> Christophe.
>
> Le 16 avr. 2013 à 11:02, Frank Shearar a écrit :
>
>> On 16 April 2013 09:53, Stephan Eggermont <step...@stack.nl> wrote:
>>> Hi,
>>>
>>> While working with Diego on some configurations, we noticed two different
>>> styles
>>> of describing the latest non-baseline versions.
>>>
>>> In one, the versionString version of a dependency is used.
>>> That is a defensive strategy, where you want to specify the exact version
>>> that
>>> will be loaded (and has been tested).
>>>
>>> In the other the #stable version is used. That is an optimistic strategy.
>>> This is much less brittle (but might suddenly not work anymore).
>>>
>>> Seaside uses defensive/mixed, while Magritte uses optimistic
>>>
>>> Based on what criteria should I choose which one to use (in a Pharo
>>> context)?
>>
>> I'd argue that since you're declaring that a certain set of versions
>> of packages work together, you should _always_ use explicit versions.
>> The "optimistic" strategy leaves you vulnerable to third parties
>> making seemingly innocuous changes that break your code. (I've been
>> bitten by this, by making such an apparently innocuous change.)
>>
>> frank
>>
>>> Stephan & Diego
>>
>
