On 2013-04-16, at 23:25, Frank Shearar <frank.shea...@gmail.com> wrote:
> 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. ... and that is more precisely: tests and continuous integration I liked ruby-gems approach more than the one in Metacello. You usually specify a major version (as under linux) for your dependency. That means the dependency might evolve a bit, typically for bugfixes, without you having to update the configuration manually. http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. As you say, #stable and #development are mostly for humans.
