On 16 April 2013 19:52, stephane ducasse <stephane.duca...@free.fr> wrote: > 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 :)
Well, #stable is for people, not machines. It's how you decide whether to try Foo 1.3 or Foo 1.4. If you're just using the library, that's one thing - use other people's #stable releases. But if you're writing a library, and other people will use your application (that uses other stuff), that's when tight control over versions pays off. Your users can know the precise things they need to run your software. frank > 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 > > > >
