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 <stephan@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