Closed scotje closed 9 years ago
I'm more inclined to leave it as is and if that is the case in the future users can explicitly add the constraint themselves. I've seen too many cases where a constraint set early screws up downstream users that want to use a newer version
The proposed constraint allows everything < 2.0.0. In the current scenario, if we push a puppet_forge 2.x, anyone who has not independently constrained on puppet_forge 1.x is likely going to break their install the next time they gem update
or bundle update
.
If it turns out that existing versions of librarian-puppet are compatible with puppet_forge 2.x, it seems simple enough to publish a z-release with an expanded dependency range so people can upgrade.
Obviously it's up to you guys what you want to do. Consider this an early heads up that a 2.x puppet_forge is looking pretty likely at this point and it will almost certainly not be fully backwards compatible with the 1.x series.
I misunderstood, if you already know that is not backwards compatible then it makes sense
At some point there will probably be a 2.x release of the puppet_forge gem that may not be backwards compatible. Pessimistic version constraints on dependencies is also a RubyGems best practice: http://guides.rubygems.org/patterns/#declaring-dependencies