Shorthand syntax for ranges like ">=1.2 <2.0"?

[guiprav]

I'm guessing this has already been brought up in the past, but I couldn't find this discussion on the web. I'm sorry if this is a recurring question.

In my understanding of semver v2, it should be safe (and desirable, I think) to install packages of greater Minor versions than the minimal one with which the package was originally implemented, because Minor bumps should be backwards-compatible.

Desirability comes from the idea that if I implement something that depends on module abc@1.2.3 at one point, and abc evolves a lot and reaches version 1.9.9, version 1.9.9 is likely to have improvements over 1.2.3 funcionality that were not introduced as 1.2 bugfixes.

It takes a very diligent maintainer to fix a bug of 1.2 functionality on version 1.9.x and create a 1.2 bugfix for it. In fact, he would need to create one bugfix for each Minor version in the 1.2~1.9 range, or at least for each tag in that range. Normally, they just tell you to update the package if you encounter problems, which is fine, but currently that's only automatically done by npm in bugfix increments, since people are instructed to use 1.2.x notation.

Even though Minor bumps mostly introduce new functionality, they may also introduce bugfixes that I would like npm to install for me without requiring me to update my package.json.

Thoughts?

[atuttle]

Set your dependency to version 1.x.x?
On Jul 6, 2013 5:42 AM, "Guilherme Prá Vieira" notifications@github.com
wrote:

I'm guessing this has already been brought up in the past, but I couldn't
find this discussion on the web. I'm sorry if this is a recurring question.

In my understanding of semver v2, it should be safe (and desirable, I
think) to install packages of greater Minor versions than the minimal one
with which the package was originally implemented, because Minor bumps
should be backwards-compatible.

Desirability comes from the idea that if I implement something that
depends on module abc@1.2.3 at one point, and abc evolves a lot and
reaches version 1.9.9, version 1.9.9 is likely to have improvements over
1.2.3 funcionality that were not introduced as 1.2 bugfixes.

It takes a very diligent maintainer to fix a bug of 1.2 functionality on
version 1.9 and create a 1.2 bugfix for it. In fact, he would need to
create one bugfix for each Minor version in the 1.2~1.9 range. Normally,
they just tell you to update the package if you encounter problems, which
is fine, but currently that's only automatically done by npm in bugfix
increments, since people are instructed to use 1.2.x notation.

Even though Minor bumps mostly introduce new functionality, they may also
introduce bugfixes that I would like npm to install for me without
requiring me to update my package.json.

Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com/isaacs/node-semver/issues/38
.

[guiprav]

In that case it's not clear what's the minimal Minor version the module is
intended to work with.

On Sat, Jul 6, 2013 at 10:16 AM, Adam Tuttle notifications@git.luolix.topwrote:

Set your dependency to version 1.x.x?
On Jul 6, 2013 5:42 AM, "Guilherme Prá Vieira" notifications@github.com
wrote:

I'm guessing this has already been brought up in the past, but I
couldn't
find this discussion on the web. I'm sorry if this is a recurring
question.

In my understanding of semver v2, it should be safe (and desirable, I
think) to install packages of greater Minor versions than the minimal
one
with which the package was originally implemented, because Minor bumps
should be backwards-compatible.

Desirability comes from the idea that if I implement something that
depends on module abc@1.2.3 at one point, and abc evolves a lot and
reaches version 1.9.9, version 1.9.9 is likely to have improvements over
1.2.3 funcionality that were not introduced as 1.2 bugfixes.

It takes a very diligent maintainer to fix a bug of 1.2 functionality on
version 1.9 and create a 1.2 bugfix for it. In fact, he would need to
create one bugfix for each Minor version in the 1.2~1.9 range. Normally,
they just tell you to update the package if you encounter problems,
which
is fine, but currently that's only automatically done by npm in bugfix
increments, since people are instructed to use 1.2.x notation.

Even though Minor bumps mostly introduce new functionality, they may
also
introduce bugfixes that I would like npm to install for me without
requiring me to update my package.json.

Thoughts?

—
Reply to this email directly or view it on GitHub<
https://github.com/isaacs/node-semver/issues/38>
.

—
Reply to this email directly or view it on GitHubhttps://github.com/isaacs/node-semver/issues/38#issuecomment-20554242
.

[isaacs]

How about >=1.2 <2.0? That would actually work just fine :)

It sounds like you're looking for a looser ~, though, right? Currently, there's nothing like that. What would you think makes sense?

[guiprav]

You're right, >=1.2 <2.0 does work just fine. And yeah, that can indeed be described as a looser ~.

I would say, if you consider this behavior interesting like I do, that's actually the behavior I'd expect from the tilde. I don't think its current meaning matches any meaninful semver understanding. Why would you not accept Minor updates? Since they are to be backwards compatible, the only reason would be to avoid bigger dependencies, and I don't think that's so important, do you? Granted, incorporating bugfixes in greater Minor versions would be much more important than that.

Of course, the loosened tilde should still match no prerelease versions.

Also, because of the nature of Minor bumps, loosening the current implementation of the tilde shouldn't break anything either. It could even be done in node-semver's next Minor release even.

I know this may sound minor (no pun intended), but once you give it some thought, let me know your rationale not to loosen ~. Maybe I'm missing something.

[agnoster]

I was also a little surprised to discover that ~ doesn't behave the way described in this issue, but I'm fairly sure it's too late to change now (well, without a major version bump to semver and thus npm, which... well, I think it's obvious that's undesirable).

However, it does seem that it would make sense for there to be a shorthand for this, since it really should be in a sense the "default" - it maps closest to the meaning "I require at minimum package level X, but would like all backwards-compatible updates". ~> would be fairly logical, but is already considered a synonym for ~, so that's eliminated, and using >~ would just be confusing.

Here's two options that might not suck too much for the proposed operator:

• ^1.2.3 has a sort of nice implication of "1.2.3 and up", while being clearly distinct from >1.2.3. Downside: caret isn't a super-common character and is not always guaranteed to be present on non-US keymaps.
• /1.2.3 can be read both logically as a sort of "absolute path", and also visually represents an increasing range (imagine a graph of a function over time with a clear lower and upper bound).

Of course there are plenty of other options, and I think it's far less important which particular operator is used than that there is one. Ideally someday maybe it could even be the default for npm install --save and friends, though it would take quite some time - as long as there are versions of npm out there without the operator, it would be problematic to use the new operator in any package.json, but that doesn't mean we can't start paving the road ;-)