Le 23/01/2016 15:44, Mariano Martinez Peck a écrit :
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.
Yes. What is interesting is I can just target the baseline of
OSSubprocess in that case, using that url
github://marianopeck/OSSubprocess:v0.2.0/repository
which is convenient.
Thierry
