New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

special-case for 0.x in ^ is very counter-inutitive and rage-inducing #79

Closed
substack opened this Issue Apr 21, 2014 · 19 comments

Comments

Projects
None yet
10 participants
@substack

substack commented Apr 21, 2014

I just started using ^ but am now completely stripping out ^ everywhere because the special case with 0.x makes it extremely counter-intuitive behavior, especially where swapping ~ for ^ is concerned.

I just went through a package.json recently and was pulling my hair out trying to figure out why "duplexer2": "^0.0.1" wasn't installing 0.0.2 until I found #41.

We currently have no way of tersely describing "up to the next major release" without special cases for 0.x. As it stands I'm not going to be using ^ anymore anywhere.

@KoryNunn

This comment has been minimized.

Show comment
Hide comment
@KoryNunn

KoryNunn Apr 21, 2014

I've started using < 1.0.0 for modules I consider to be not ready for general use. Anything that I think is ready for other people, i make v1.0.0, and go from there.

I understand where you are coming from though, as probably 50 of my modules are < 1, and I run into the same issue constantly. I'm re-versioning them as I come across them.

KoryNunn commented Apr 21, 2014

I've started using < 1.0.0 for modules I consider to be not ready for general use. Anything that I think is ready for other people, i make v1.0.0, and go from there.

I understand where you are coming from though, as probably 50 of my modules are < 1, and I run into the same issue constantly. I'm re-versioning them as I come across them.

@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Apr 21, 2014

There is a reason why all my new modules start at version 1.0.0 . The same goes for @dominictarr

I believe @isaacs did a survey of what users of npm thought ^ meant and implemented rules based on the survey results.

We should make a PR on npm so that npm init defaults the version to 1.0.0

Raynos commented Apr 21, 2014

There is a reason why all my new modules start at version 1.0.0 . The same goes for @dominictarr

I believe @isaacs did a survey of what users of npm thought ^ meant and implemented rules based on the survey results.

We should make a PR on npm so that npm init defaults the version to 1.0.0

@shime

This comment has been minimized.

Show comment
Hide comment
@shime

shime Apr 21, 2014

@Raynos so all modules would initially be marked as stable? I don't think that's a good workaround.

shime commented Apr 21, 2014

@Raynos so all modules would initially be marked as stable? I don't think that's a good workaround.

@timoxley

This comment has been minimized.

Show comment
Hide comment
@timoxley

timoxley Apr 21, 2014

Member

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Source

This is actually part of the spec and it's awfully confusing and prone to abuse.

so all modules would initially be marked as stable?

What does 'stable' even mean though? There's plenty of modules that never, ever change their API, so you could consider them 'stable' but never live to break away from 0.x because of this illogical fear of major version number commitment.

There is a reason why all my new modules start at version 1.0.0

The npm ecosystem is infamous for being of flakey quality and everything being perpetually stuck in 0.x doesn't help as it mostly defeats purpose of using semver at all.

Going 1.x out of the box might help decrease people's threshold for what constitutes acceptably "stable", and increase people's sense of responsibility to not break API's and overall getting more people using semver correctly.

Member

timoxley commented Apr 21, 2014

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Source

This is actually part of the spec and it's awfully confusing and prone to abuse.

so all modules would initially be marked as stable?

What does 'stable' even mean though? There's plenty of modules that never, ever change their API, so you could consider them 'stable' but never live to break away from 0.x because of this illogical fear of major version number commitment.

There is a reason why all my new modules start at version 1.0.0

The npm ecosystem is infamous for being of flakey quality and everything being perpetually stuck in 0.x doesn't help as it mostly defeats purpose of using semver at all.

Going 1.x out of the box might help decrease people's threshold for what constitutes acceptably "stable", and increase people's sense of responsibility to not break API's and overall getting more people using semver correctly.

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 21, 2014

@Raynos no, @isaacs implemented the official spec... which is a bit bloated.
check this discussion: dominictarr/semver-ftw#2

it's the most explicit is to either use >=min <max or start every module at 1.0.0
("semver the good parts")

dominictarr commented Apr 21, 2014

@Raynos no, @isaacs implemented the official spec... which is a bit bloated.
check this discussion: dominictarr/semver-ftw#2

it's the most explicit is to either use >=min <max or start every module at 1.0.0
("semver the good parts")

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 21, 2014

the worst part of semver is that it couples a representation of the change with future expectations of stability. These two things should be independent. Still want to indicate the nature of the change even if the module is not stable.

dominictarr commented Apr 21, 2014

the worst part of semver is that it couples a representation of the change with future expectations of stability. These two things should be independent. Still want to indicate the nature of the change even if the module is not stable.

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Apr 21, 2014

What @dominictarr said bugs the heck out of me too.

aredridel commented Apr 21, 2014

What @dominictarr said bugs the heck out of me too.

@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Apr 21, 2014

@shime it works great.

I have a module at v7.2.0 which means i broke back compat 6 times in its life cycle.

most of my 1.0.0 initial commits are pretty solid and when i do need to change the module i just bump major.

Raynos commented Apr 21, 2014

@shime it works great.

I have a module at v7.2.0 which means i broke back compat 6 times in its life cycle.

most of my 1.0.0 initial commits are pretty solid and when i do need to change the module i just bump major.

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 21, 2014

@aredridel prehaps the best compromize that is closest to spec following is to use semver the good parts, plus, use the same spec but shifted across one (and just 0.Major.minor-patch, when not stable)

But even better is just use simple semver, and just indicate stability separately in the documentation.

dominictarr commented Apr 21, 2014

@aredridel prehaps the best compromize that is closest to spec following is to use semver the good parts, plus, use the same spec but shifted across one (and just 0.Major.minor-patch, when not stable)

But even better is just use simple semver, and just indicate stability separately in the documentation.

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 21, 2014

also, using ^ will break all the node@0.8 tests on travis.

dominictarr commented Apr 21, 2014

also, using ^ will break all the node@0.8 tests on travis.

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Apr 21, 2014

Yes, that's my strategy so far. Stability is complex, so needs documentation and discussion. I just label my interface compatibility.

aredridel commented Apr 21, 2014

Yes, that's my strategy so far. Stability is complex, so needs documentation and discussion. I just label my interface compatibility.

@thomblake

This comment has been minimized.

Show comment
Hide comment
@thomblake

thomblake Apr 21, 2014

Agree, people should be going to 1.0 sooner and just bump major when they need to. Don't stop using ^, just stop using 0.x modules and expecting semver to work.

thomblake commented Apr 21, 2014

Agree, people should be going to 1.0 sooner and just bump major when they need to. Don't stop using ^, just stop using 0.x modules and expecting semver to work.

@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Apr 21, 2014

@dominictarr preinstall: npm i npm@latest -g for 0.8 travis fix.

Raynos commented Apr 21, 2014

@dominictarr preinstall: npm i npm@latest -g for 0.8 travis fix.

@pda

This comment has been minimized.

Show comment
Hide comment
@pda

pda Apr 21, 2014

Seems ^ reflects exactly how http://semver.org/ works, especially regarding 0.y.z releases which http://semver.org/ specifically special-cases in this way.

I'd love to see this ported to RubyGems etc. And I'd love to see people stop depending on 0.y.z releases.

pda commented Apr 21, 2014

Seems ^ reflects exactly how http://semver.org/ works, especially regarding 0.y.z releases which http://semver.org/ specifically special-cases in this way.

I'd love to see this ported to RubyGems etc. And I'd love to see people stop depending on 0.y.z releases.

@isaacs

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Apr 21, 2014

Member

The ^ range operator does exactly what the SemVer spec says to do.

If you're using version numbers differently from how the SemVer spec suggests, then I'm fine with that. npm config set save-prefix="~" or if you feel like being a little crazy, npm config set save-prefix=">=", or if you feel like being less crazy, npm config set save-exact=true.

So, no, we're not going to change the default. It's configurable. Set it however you want.

I think that maybe we could do a patch release of 0.8 for Travis just to get a newer node-semver in there, though. Would that be worthwhile? Or would it be better to just hasten 0.8's inevitable decline and deprecation?

Member

isaacs commented Apr 21, 2014

The ^ range operator does exactly what the SemVer spec says to do.

If you're using version numbers differently from how the SemVer spec suggests, then I'm fine with that. npm config set save-prefix="~" or if you feel like being a little crazy, npm config set save-prefix=">=", or if you feel like being less crazy, npm config set save-exact=true.

So, no, we're not going to change the default. It's configurable. Set it however you want.

I think that maybe we could do a patch release of 0.8 for Travis just to get a newer node-semver in there, though. Would that be worthwhile? Or would it be better to just hasten 0.8's inevitable decline and deprecation?

@isaacs isaacs closed this Apr 21, 2014

@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Apr 21, 2014

@isaacs I think if we #ship 0.12 then we can remove 0.8 from all our travis files.

cc @tjfontaine #shipit

Raynos commented Apr 21, 2014

@isaacs I think if we #ship 0.12 then we can remove 0.8 from all our travis files.

cc @tjfontaine #shipit

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 22, 2014

@Raynos but won't that cause everyone who installs your module to update to the latest npm?
That feels like crossing a line to me.

dominictarr commented Apr 22, 2014

@Raynos but won't that cause everyone who installs your module to update to the latest npm?
That feels like crossing a line to me.

@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Apr 22, 2014

@dominictarr i meant the travis preinstall hook in the .travis.yml file. not the npm scripts preinstall hook (dont use that one ever)

Raynos commented Apr 22, 2014

@dominictarr i meant the travis preinstall hook in the .travis.yml file. not the npm scripts preinstall hook (dont use that one ever)

@dominictarr

This comment has been minimized.

Show comment
Hide comment
@dominictarr

dominictarr Apr 22, 2014

@Raynos yes - okay I can rest easy now.

dominictarr commented Apr 22, 2014

@Raynos yes - okay I can rest easy now.

demands referenced this issue in goodeggs/mongoose-webdriver Oct 13, 2014

Changes that should probably be a part of our yeoman generator
Also things I had to do:

git commit -m "Module generated by goodeggs-npm"
git push --set-upstream origin master

Add a project description on GitHub

hurrymaplelad referenced this issue in npm/init-package-json Oct 27, 2014

Default to version 1.0.0
Since the SemVer spec is weirdly magical about 0.x.y versions, and we
cannot ever hope to get everyone to believe what the correct
interpretation of 0.x versions are, let's just skip them entirely.

@pgmemk pgmemk referenced this issue Jul 14, 2015

Closed

Peer sem ver #6

vladimyr added a commit to vladimyr/bili that referenced this issue Oct 2, 2018

Upgrade rollup to ">=0.60.0 <1" 🎉
- addressing semver ^0.x special case:
  npm/node-semver#79
- bumping from v0.57 to v0.60 per rollup-plugin-babel requirement
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment