Caret by default

[sdboyer]

We need a way of simulating carat-by-default behavior. That is, if you call semver.NewConstraint("1.0.0"), it will interpret that as "^1.0.0". To get only and exactly that version, you'd have to call semver.NewConstraint("=1.0.0").

When I started looking at this, it had more far-reaching implications than I initially thought :(

[mattfarina]

To restate, this is about switching the default, when no range is provided, from = to ^.

What is the motivation? Use case? I'm not familiar with the background and would like to come up to speed.

[sdboyer]

To restate, this is about switching the default, when no range is provided, from = to ^.

Yup.

What is the motivation? Use case? I'm not familiar with the background and would like to come up to speed.

The pm committee decided to do this a while back. The motivation is providing a nudge in the direction of being open within what should be a safe range. It's also taking a cue from cargo.

The string "0.1.12" is a semver version requirement. Since this string does not have any operators in it, it is interpreted the same way as if we had specified "^0.1.12", which is called a caret requirement.

[mattfarina]

Before I say go forth... I'm curious if this should be in the semver library or the application code that passes it in. I'd like to ponder this.

@technosophos any thoughts? I ask because helm uses semver.

[sdboyer]

I think I'd considered doing it that way in the past, but...well, I can't remember offhand what stopped me. I think there may end up being subtle dependencies that make it hard for gps to ensure everything's done correctly, at least.

I'll look into it again, though.

[mattfarina]

@sdboyer I just want to take a moment to consider multiple angles. Don't beat yourself up over it.

[mattfarina]

@sdboyer what do you think of providing the ability to set the default when no range is supplied? Then setting the default default to ^.

[sdboyer]

@mattfarina That might work. Could you possibly work up some quick pseudocode to demonstrate what you have in mind, to make sure I'm understanding your suggestion correctly?

[technosophos]

Ugh.. please don't change the default to "If I specify an exact version, I mean not an exact version." That's sooooo not user friendly, and soooo backwards compatibility breaking.

[sdboyer]

That's the plan for how it's going to work in dep. The only question (in this issue) is how that integrates with what's here.

[technosophos]

Yeah, Dep can do whatever. I have no preference about that. But changing Semver is a breaking change, and since this is a string format thing, it would require us (for example) to potentially make thousands of changes to existing Helm charts. it would also potentially break backward compatibility with Glide, which (as you know) has a pretty substantial user base at this point.

[sdboyer]

But changing Semver is a breaking change

Right - this would certainly only be for the 2.x line.

My concern there is that, if dep is to implement autoconversion from glide.yaml files - which it almost certainly will at dep init time, though it's not yet clear if it will during solving - then either semver 2.x will need to adaptively support either mode of operation, or...well, I'm not sure there's an or. And, as you note:

it would also potentially break backward compatibility with Glide

Adaptively supporting either mode is tricky, not at the string parsing layer (there could be a different entry point, or a flag on NewConstraint that allows the user to choose carat-by-default or not), but at string generation time - Constraint.String() won't know whether to render a carat-expressible range with or without the carat.

We could also overcome that with a special ToString(c Constraint, cbd bool) string wrapper that lets the user designate carat-by-default behavior (same idea as with the inputs), but then we're breaking Stringer simplicity.

It's ughs all around.

[technosophos]

Sounds to me like the path of least resistance is for dep to continue to use x.y.z as implying an exact version, not an implied ^.

[sdboyer]

Oh, that would definitely be the path of least resistance. But I'm hoping to avoid having that dictate the outcome, if possible.