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. so I would specify a dependency with a versionString for release versions of your lib/tool. It ensures a minimum version.
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 >
smime.p7s
Description: S/MIME cryptographic signature
