On 2013-04-16, at 23:25, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 April 2013 19:52, stephane ducasse <stephane.ducasse@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.