Le 23/01/2016 17:17, Mariano Martinez Peck a écrit :
On Sat, Jan 23, 2016 at 12:42 PM, Thierry Goubier <[email protected] <mailto:[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, I know, I implemented part of that support into gitfiletree urls (commit ids and tags don't work with git clone, of course).
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>]
I was thinking of the wildcard support Dale implemented ;) Thierry
:) -- Mariano http://marianopeck.wordpress.com
