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 :)
Thierry
