Allow semantic ranges for orb versions | Orbs

Allow semantic ranges for orb versions

closed

James Nail

I'd like to be able to use an orb based on a semantic range, like you might do with npm dependencies.
For example, this:
orbs:  some-orb: random-company/some-orb@^1.2.0
would resolve to the newest version at or above 1.2, but under 2.0.
CCI-I-1078

June 27, 2019

Oran Wilder

marked this post as

closed

Closing this per the docs linked below. For example, you may invoke the newest 1.x version of an orb using orb-name@1.

Kyle Tryon

Hello all,Semantic versioning already includes automatic updating based on the version number given. For more information on how semantic versioning works, please see our updated documentation here:https://circleci.com/docs/2.0/orb-concepts/#semantic-versioning

Nathan Dintenfass

In case it's not clear to those reading this thread, you are able to say

to get the newest

1.x.y

1.2

to get the newest of

1.2.x

-- right now we don't have plans to expand beyond that. If that doesn't suit your needs can you elaborate on the scenario you need to set with more fine-grained controls?

Alex Lopez

I'd also like to see this implemented.
Nathan Dintenfass: I don't know if it's necessarily about more fine-grained controls, but rather about making better use of semver. To be honest, I don't think that the way it currently works makes a lot of sense from a semver perspective. The main point of semver is that only major versions are supposed to introduce breaking changes, so pinning to a minor version doesn't make a whole lot of sense.
E.g. if I add a completely new configuration component to an orb without changing anything else, that should be a minor version (new feature which doesn't break compatibility). I may want to indicate (even if just for the sake of documentation and traceability) that my config depends on that particular new feature, while still wanting to get the newest compatible version (according to semver's semantics).
What we end up doing is locking to the major version (as per the docs), which more or less works in practice for this purpose, but it's not too satisfactory in that it doesn't reflect the actual dependency.