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

[ghost]

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]

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]

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]

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

[timoxley]

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]

@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]

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]

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

[Raynos]

@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]

@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]

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

[aredridel]

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

[tamzinblake]

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]

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

[pda]

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]

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?

[Raynos]

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

cc @tjfontaine #shipit

[dominictarr]

@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]

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

[dominictarr]

@Raynos yes - okay I can rest easy now.