Inventory client - list_metrics_for_resource doesn't work for nested resources

[jkremser]

https://github.com/hawkular/hawkular-client-ruby/blob/master/lib/hawkular/inventory/inventory_api.rb#L261

the implementation takes a resource hash as a parameter and then escapes it's id, but it doesn't honor the resource ids of parent resources

[pilhuhn]

This needs to go in to 0.2.2 and 0.3

[jkremser]

Fix for 0.2.x is in the 0.2.x branch and fix for 0.3.0 is addressed by PR #55

[abonas]

@pilhuhn @Jiri-Kremser could you please explain the various versions/branches that you are managing for the gem? why is it not just released sequentially from the gem's master?

[pilhuhn]

On 25 Apr 2016, at 12:26, abonas wrote: @pilhuhn @Jiri-Kremser could you please explain the various versions/branches that you are managing for the gem? why is it not just released sequentially from the gem's master?

Gem's master has/will have incompatible changes. 0.2.2 was needed as some inventory related things were done wrong.

[abonas]

@pilhuhn afaik for incompatible changes, there's a need for a major version change.
e.g. X.Y.Z -> the X has to change.
please see here:
http://guides.rubygems.org/patterns/#semantic-versioning

[jkremser]

@abonas sure, we try to be compliant with the sem-ver. But we needed to fix the issue also for the pre 0.2.x versions. While master was already on 0.3.0.

I was wondering if this is a good thing to have the version set to 0.3.0 even though the 0.3.0 hasn't been released yet. So it's like 0.3.0-SNAPSHOT from maven rather than real 0.3.0

[abonas]

Where do you want to set the version to 0.3.0? on master? from my experience - less common.
typically you would have several commits merged to master, then change the version and immediately release the gem. btw I hope you are releasing by (just faster than doing that via gem commands)
rake build & rake release

[abonas]

and also, if the planned 0.3.0 is backwards incompatible, then it should be something like 1.0 and not 0.3.0.

[jkremser]

Where do you want to set the version to 0.3.0? on master? from my experience - less common.

cool, I like it more, but when I started working on hawkular-client-ruby the first was the case, so I used the same methodology.

and also, if the planned 0.3.0 is backwards incompatible, then it should be something like 1.0 and not 0.3.0.

Well, that's questionable, because the way semantic versioning works in Ruby is ... ehm, "special" :) Because it doesn't work the same way as commonly used http://semver.org in 1 particular case.

0.y.z

Ruby says the every breaking change should enforce the major++.

But according the semver.org:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
http://semver.org/#spec-item-4

So it depends if we want to use Ruby semantic versioning, or the "semver.org" semantic versioning :]

btw. Once the 1.0.0 is out, it should be the same.

[abonas]

So it depends if we want to use Ruby semantic versioning, or the "semver.org" semantic versioning :]

btw. Once the 1.0.0 is out, it should be the same.

imo since this is a Ruby gem, it lives in "Ruby land" and is published on rubygems, the Ruby gem versioning rules should be applied. Understanding its versioning by other Ruby developers will be most likely done by Ruby ver rules and not other rules.