[Hawkular-dev] Inventory to break its REST API

[Thomas Heute]

On 03/13/2015 12:26 AM, mike thompson wrote:
>> On 12 Mar 2015, at 16:18, Lukas Krejci <lkrejci at redhat.com> wrote:
>>
>> 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?
> If Jirka did the integration I would feel confident and it would solve the resources issue. Now, ultimately this is a Thomas/Heiko call as they are doing the demo. ;)

I talked to Lukas prior to the email, I would like to see it integrated, 
but said that this would have to be merged once that works and not 
affect the UI team. For the UI effort to use the new API, this should be 
purely on Lukas/Jirka.
That means Lukas and Jirka work in a branch (rebase often) until this 
works properly and then merge. (If it doesn't "work fine" on time we 
won't merge for this milestone).

Thomas

>
>>>>>> 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
>> _______________________________________________
>> 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