Hi Thierry, > On Jan 23, 2016, at 8:38 AM, Thierry Goubier <[email protected]> > wrote: > > Hi Eliot, > > Le 23/01/2016 17:04, Eliot Miranda a écrit : >> Hi Both, Hi Dale, >> >>> On Jan 23, 2016, at 7:42 AM, 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. >>> >>> 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. > > Well, if you take a Travis / Github integration and you fetch from branch > 1.23, then you should only merge into that branch with a pull request if the > tests are green. Moreover, with Metacello, baselines and branches you allways > target the newest version; as long as your CI ensure that tests are green > before merging into public/stable branches, then that already works. > > The branch methodology would look like that, then: > > - one branch for each stable / long lived version with garanteed API > compatibility > - v1.1 > - one tag for each released version, when merged in their right overall branch > - v1.1.0, v1.1.1, v1.1.2, v1.1.3 (inside branch v1.1) > - development branches for the main work. > - and an integrated CI like travis so that no merge can be done in a release > branch without having everything green. > > Like that, if you target v1.1, you'll get the latest green version on API 1.1 > :)
Listening to Stephan I think the key point is "with the minimum amount of manual work". Of course I can use the process above. But if what the tests were to run were specified in code or as package metadata, and the ci to run the tests was "available as a service" without my having to configure, then I wouldn't need to manually manage the process of only committing to the public version when the tests were green; the system would do that for me. The only thing I'd have to do as a designer is name or version the API if it needed to evolve. > > Thierry >
