Am 24.02.2015 um 20:01 schrieb John Mazzitelli
<mazz(a)redhat.com>:
to merge it, up the version number, release it, then go to the kettle repo, up the
version number of the bus artifacts, create PR/merge it, and release it. People would
still be waiting for a good kettle build :)
Actually this morning (MET) Travis did not have a good build, because a not-yet-built
dependency was
introduced and hawkular/kettle was not finding it.
This seems to finally build again after kicking all the individual CI builds in correct
order.
Asking that we need to be able to apply duct tape all over the mistakes we made a few
minutes ago
when not following the more strict rules that could have prevent havoc in the first place,
may be a flawed argument.
I like the absolute freedom to be able to just commit what I want.
On the other hand I make mistakes and it is good that peer review and CI can catch them
before they hit master.
What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on metrics-M345 and
inventory-M23 ?
Also with the idea of "release early, release often" and "make small
customer visible changes", master and
the PRs should not diverge too much, but will allow PR-builds to depend on a defined set
of dependencies.
Today when you say "depends on bla-SNAPSHOT", you don't know what version of
bla-SNAPSHOT will
be used in CI (or later even in CD ).
Instead of using Milestones (Mxxx) we can also introduce/use timestamped snapshots.
And Lukas: Now suppose you change the inventory-implementation to the future branch, which
has a different REST-api, different domain objects and a few other things. Once that hits
master, every other component depending on Inventory (UI , Pinger, ??) will
fail as they just pull the new snapshot and have compile or runtime failures. With some
"luck" you only see that after someone assembles the Kettle and runs it.
Here allowing the UI / Pinger to still build/run against inventory-current will help to
transition them over to the new api, as the Kettle will still build and work. And only if
the Pinger dev explicitly says "Now I want inventory-future and have changed my
code", that breakage is prevented. And yes, I know this still requires the 3
components being introduced in lock-step, which could be prevented by content-negotiation,
which we need to introduce once the existing apis have stabilized.