Hi Both, Hi Dale, > On Jan 23, 2016, at 7:42 AM, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > 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
Maybe soon enough we can find a way of integrating CI server test results for specific packages with Metacello and talk not about #stable, but #greenest. Green means tests have passed, but i think the connotation of green=young is common too, no? (viño verde). This doesn't protect against API changes, when the tests get changed to match the new API, but that implies versioning the API separately from the package so one can ask for #greenest #api=1.23.
