You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a cookbook that works fine with both the 5.x and 6.x versions of one of its dependencies. However, obviously it may or may not work with a future 7.x version. I want to allow projects that use my cookbook to update to the 6.x dependency version, but without introducing a breaking change to force them.
I thought I'd be able to specify > 5.1 <= 7.0 in some format, but it seems that there's no way to express that. I've tried various formats including arrays etc, but everything I try just gives did not contain a valid operator or a valid version string.
I appreciate it would be a nightmare to support arbitrary non-contiguous ranges, but it would be great to have basically a slightly-less-pessimistic constraint somehow. Apologies if this exists, but I can't find it documented or by trial and error.
The text was updated successfully, but these errors were encountered:
acoulton
added a commit
to ingenerator/chef-duplicity-backup
that referenced
this issue
Feb 17, 2017
Their breaking change doesn't affect us. Had to make the constraint
looser as per berkshelf/semverse#10 there
doesn't seem to be a way to specify >=5.1 <7.0
I have a cookbook that works fine with both the 5.x and 6.x versions of one of its dependencies. However, obviously it may or may not work with a future 7.x version. I want to allow projects that use my cookbook to update to the 6.x dependency version, but without introducing a breaking change to force them.
I thought I'd be able to specify
> 5.1 <= 7.0
in some format, but it seems that there's no way to express that. I've tried various formats including arrays etc, but everything I try just givesdid not contain a valid operator or a valid version string
.I appreciate it would be a nightmare to support arbitrary non-contiguous ranges, but it would be great to have basically a slightly-less-pessimistic constraint somehow. Apologies if this exists, but I can't find it documented or by trial and error.
The text was updated successfully, but these errors were encountered: