Inventory client - list_metrics_for_resource doesn't work for nested resources about hawkular-client-ruby HOT 10 CLOSED

This needs to go in to 0.2.2 and 0.3

from hawkular-client-ruby.

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

from hawkular-client-ruby.

@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?

from hawkular-client-ruby.

from hawkular-client-ruby.

@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

from hawkular-client-ruby.

@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

from hawkular-client-ruby.

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

from hawkular-client-ruby.

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

from hawkular-client-ruby.

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.

from hawkular-client-ruby.

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.

from hawkular-client-ruby.