Hi Thierry, The Metacello answer here would be "it's up to you" hahahaha. I don't have a strong opinion. Most of the times I am in the similar situation, I tend to use fixed versions when the projects are really coupled and one cannot work without the other. And use #stable when they are less coupled and I would not die if that dependency is broken for some time until fixed. What would be the problem of using #stable? That I may release new versions which may break the user API, or I may introduce bugs that I didn't discover before, etc etc. It won't be fun if I update GitFileTree and suddenly I cannot commit anymore. But at the same time, you don't expect a user to be updating GitFileTree in his image. In addition, you have a CI that will tell you immediately if the build fail or your tests failed. If you ask me, I think I would use fixed versions. Then, whenever I release a new version, you give it a try, you test it, you try it in the CI, etc. If everything seems to work, then I would update your conf and point to new version. Cheers, On Sat, Jan 23, 2016 at 9:09 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi,
I'm looking at OSSubprocess use as a requirement for GitFileTree and I wonder if it is wise to list the dependency on OSSubprocess #stable or to set to a specific version (v0.2)?
Thanks,
Thierry
-- Mariano http://marianopeck.wordpress.com