[Hawkular-dev] Inventory to break its REST API

Lukas Krejci lkrejci at redhat.com
Thu Mar 12 19:18:44 EDT 2015


On Thursday, March 12, 2015 16:05:27 mike thompson wrote:
> > On 12 Mar 2015, at 13:56, Lukas Krejci <lkrejci at redhat.com> wrote:
> > 
> > On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
> >> Hello,
> >> 
> >> It is not so much of a vote but an example of what Hawkular Metrics has
> >> been doing. The project has been released on 0.x.y version under RHQ
> >> Metrics name and will continue to get released under the same version
> >> scheme under the Hawkular organization. But Metrics is a little bit
> >> atypical because we had official releases along the way and will keep
> >> releasing. If you plan on getting community releases then it might be a
> >> good idea to use 0.x.y until the API is stable and the project matures.
> > 
> > I think it is a reasonable thing to do also in a multi-module project. The
> > releases don't even need to be "official" - it's just an acknowledgment of
> > progress with the realization that the rest of the modules might not have
> > adapted to that progress yet.
> > 
> > IMHO, going 0.x.y makes most sense for all components, not just metrics.
> > This is supported by looking for example at Artificer, that had a great
> > number of 0.x releases (called S-RAMP then) before it reached today's
> > 1.0.0.Alpha1. That milestone is significant and means that it has all the
> > features deemed for 1.0.0 and is ready for stabilization phase. All Hawk
> > components are far from that stage.
> > 
> >> Thank you,
> >> Stefan
> >> 
> >> ----- Original Message -----
> >> 
> >>> From: "Lukas Krejci" <lkrejci at redhat.com>
> >>> To: hawkular-dev at lists.jboss.org
> >>> Sent: Thursday, March 12, 2015 8:38:30 AM
> >>> Subject: [Hawkular-dev] Inventory to break its REST API
> >>> 
> >>> Hi,
> >>> 
> >>> the time has come to merge the "future" branch of inventory to its
> >>> master
> >>> so that we don't prolong the schizophrenic situation of the component.
> >>> 
> >>> Because that merge will break the REST API, we need to sort out the
> >>> recent
> >>> discussion about how to handle the breaking changes in the builds.
> 
> Hopefully the merge will not happen in the next two weeks while we are
> trying to deliver our alpha 2 MVP? There really is no time in the schedule
> to for changes this large and close to a deadline.

Well, actually this was my plan. We're out of master for more than a month 
with great deal of features missing on any integration opportunities with the 
rest of the components because of the simple fact that we don't want to break 
other people's work. There's always going to be an Alpha, Beta or GA coming 
and the longer we wait with integrating the bigger a "bomb" it is going to be.

If the breaking changes are released in a different version than what the MVP 
components are using, then there's really no reason to not merge.

But I was thinking that we should actually incorporate the "true" inventory 
code into MVP proper and do it now. Otherwise it will never get there, IMHO. 

If Jirka lent his skillful Angular hand would that still not be possible?

> >>> There were 2 proposals:
> >>> 
> >>> [ ] adopt 0.x.y versioning or some such so that we can actually increase
> >>> a
> >>> version with breaking changes *, or
> >>> [ ] release timed snapshots and depend on them rather then simple
> >>> -SNAPSHOT.
> >>> 
> >>> Please vote or propose other solutions so that we can move forward and
> >>> not
> >>> piss off whole nations..
> >>> 
> >>> Cheers,
> >>> 
> >>> Lukas
> >>> 
> >>> * semver allows 0.x to do breaking changes without increasing the major
> >>> version, because leading zero means "before the first stable release"
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev



More information about the hawkular-dev mailing list