Well.. If you follow the semantic versioning guidelines <http://semver.org/> the dependency can be done in metacello with the new scripting API like this:
github://marianopeck/OSSubprocess:v1.?/repository and this will match the newest sub-version, in this way there's no need to update dependent projects unless a major version is released (because this implies breaking changes in the public API). On Sat, Jan 23, 2016 at 11:44 AM, Mariano Martinez Peck < [email protected]> wrote: > 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 < > [email protected]> 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 >
