On Sat, Jan 23, 2016 at 12:42 PM, Thierry Goubier <[email protected] > 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. > > Yes, and not only tags, what everything (commits, branches, etc). See this post: http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.html This is the supported pattern: github://<username>/<projectname>[:<branch>|<tag>|<SHA>][/<path>] :) -- Mariano http://marianopeck.wordpress.com
