(HC-94) Unpin the hocon gem version

[HAIL9000]

Prior to this commit, the version of the hocon gem for this module
was pinned to 0.9.3. There have been several new releases since then,
but since the version is pinned in the Gemfile the module is still
using an old release of the gem.

The version was originally pinned to avoid breaking the vsphere
and azure modules, but both modules now require hocon version 1.0.0+
so it is no longer neccesary for the module to continue using an
older version.

[HAIL9000]

Oops this is failing in Travis, looks like there may be some work to be done around beaker versions. I'll take a look

[cprice404]

Would it make sense to pin this to like 1.x, or 1.2.x or something? I'm not up to speed on what our best practices are around versioning gem dependencies for modules, so I'm OK with not specifying a version range at all if that's the normal modus operandi for modules, but we've been bitten a few times in the past by the lack of determinism that results from not restricting version ranges, so I figured it was worth asking.

[HAIL9000]

/cc @DavidS for thoughts on this. We're currently working on adding hocon to modulesync and I'm not sure if we have any policies/best practices around this.

Thanks for bringing it up @cprice404!

[DavidS]

It all depends on "your" control and commitment to keep the hocon API compatible. Usually, a ~> 1.0 would be a safe choice, or ~> 1.2, if you ar depending on features from the 1.2.x series.

If you need to run tests against multiple versions of the underlying gem, you might use the location_from_env function, and expand the travis/jenkins matrices with pins to more specific versions, e.g. ~>1.0.0 through ~>1.2.0...

[cprice404]

We should have pretty much full control over the ruby hocon gem/API, and we have been following semver pretty carefully.

My vote would probably be to just go with ~>1.2.0 and not worry about multiple versions until we have a concrete use case. But if it's easy/desirable to introduce the matrix now, that's fine too. I would love to have 1.2.0 covered in tests (it should be released any minute now - @jpinsonault has just been working on the kinks on a CI release job for it).

[DavidS]

~> 1.2.0 will pin to anything 1.2.x; using ~> 1.2 will pin to anything 1.x
with x > 2; I usually recomment the latter for less churn, if you only want
to test against latest.

On 27 October 2016 at 15:22, Chris Price notifications@github.com wrote:

@cprice404 commented on this pull request.

In Gemfile #40:

@@ -27,6 +27,6 @@ else
gem 'puppet', :require => false
end

-gem 'hocon', '~> 0.9.3', :require => false

We should have pretty much full control over the ruby hocon gem/API, and
we have been following semver pretty carefully.

My vote would probably be to just go with ~>1.2.0 and not worry about
multiple versions until we have a concrete use case. But if it's
easy/desirable to introduce the matrix now, that's fine too. I would love
to have 1.2.0 covered in tests (it should be released any minute now -
@jpinsonault https://github.com/jpinsonault has just been working on
the kinks on a CI release job for it).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AABsQLGCJVbkPuC6Fx2aplhJ2lRwCNBdks5q4LO9gaJpZM4Kf8Mm
.

[HAIL9000]

Alright, thanks for the input everyone! This now has been dealt with in PR #42 which added puppetlabs-hocon to modulesync. Since it's now modulesync'd, it will get periodic updates to things like gem versions and configurations so hopefully this should minimizes issues in the future.

There was no 1.2 version of the hocon gem yet, so I pinned it to ~> 1.1. We can update it when the new version is out.