Le 23/01/2016 19:23, Eliot Miranda a écrit :
Hi Thierry,
On Jan 23, 2016, at 8:38 AM, Thierry Goubier
<thierry.goub...@gmail.com> 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
<thierry.goub...@gmail.com> 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.
I certainly agree with that "minimum amount of manual work", and this is
why I'm looking for the less friction setup: one that doesn't require me
to update a few configurations in addition to merging and checking my
integration tests.
However, I would prefer to have, when releasing, a decision where I
decide to push something, when all tests are green, and not
automatically. As, for example, Dale has setup the FileTree repository,
then I can commit and push on separate branches, let CI check those, and
merge when I'm sure to a stable branch (when everything is green).
Now, having nightly builds automatically the latest green one... I guess
that can be done.
The only thing I'd have to do as a designer is name or version the
API if it needed to evolve.
But the setup you describe is a bleeding edge type of things, on which
some commits or pushes just fail the CI tests. So I'm not sure I'd like
to be a user of that.
Thierry
