[Hawkular-dev] maven stuff

[Lukas Krejci]

On Thursday, February 26, 2015 14:36:56 Heiko W.Rupp wrote:
> > Am 24.02.2015 um 20:01 schrieb John Mazzitelli <mazz at 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.
> 

Hence my proposal to go back to 0.y.z-SNAPSHOT versioning scheme and actually 
raise the version when making a breaking change. Semver (which I think would 
be a good thing to follow) allows for 0. versions to make breaking changes, 
because they are made before the first stable release - 1.0.0.

To recap - I find it to be a real issue that people have to wait for a new 
versioned build for potentially every bugfix we make in order to "align" the 
components (and this early in dev, we are misaligned all the time because of 
the pace of development on all fronts). At the same time, you are right about 
api-breaking changes causing havoc, of course.

So to solve "my" issue, I propose using snapshot builds. To solve "your" 
issue, I propose to actually increase the version on every breaking change.

But I guess depending on timed snapshots can achieve the same goal, only IMHO 
less elegantly, because with them you don't know if a breaking change was 
introduced or not.


> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev