Kill the special pre-1.0.0 meaning for ^ & ~

[rvagg]

:fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire:

Confusing and has very little, if no, practical usefulness in the real world (in my experience and opinion anyway, ymmv)

:fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire:

[DamonOehlman]

@rvagg I don't disagree and admit I found the whole "special cases" implementations very confusing. When I was implementing the ranges though, I wasn't sure quite how to break away from what had previously been implemented in an intelligent fashion. So let's thrash out what does make sense and do it that way :)

[DamonOehlman]

Is the solution to drop the special pre-1.0.0 and pre-0.1.0 meanings for both and just have ^ locking to major versions and ~ locking to minor? While I do agree with @dominictarr that having both ^ and ~ is confusing, it seems like this might be the most pragmatic solution...

If so, I think this represents revised range matches:

version	min	max
^1.2.3	1.2.3	1.65535.65535
^0.1.2	0.1.2	0.65535.65535
^0.0.1	0.0.1	0.65535.65535
~1.2.3	1.2.3	1.2.65535
~0.1.2	0.1.2	0.1.65535
~0.0.1	0.0.1	0.0.65535
1.x.x	1.0.0	1.65535.65535
1.1.x	1.1.0	1.1.65535

[rvagg]

Another solution would be to just disallow 0 as a major version, this would maintain backward-compatibility to semver and kill the special meaning in one go; I'm tempted to go this route with my Node packages in fact.

[DamonOehlman]

So just to clarify, are you are able to publish a thing with a version of 0 "major version" (e.g. 0.3.4) or is the first version that would ever be published a 1 something?

I do like having the 0 space for indicating to people that this is something that isn't yet ready for primetime, but then pushing to 1 as soon as it is (which should be sooner rather than later).

[dominictarr]

@DamonOehlman I think the source of the problem is that version numbers mean too much. the best part of semver is that it is a way to lable the changes in your interface, if you want to indicate "this is ready, come and get it" or "come and help me experiment" that is a very different thing to saying "if you depended on version 1.2.3 you may have to rewrite something to use 2.0.0"

After some discussion a while back... https://github.com/dominictarr/semver-ftw/issues/2 my evil twin convinced me that there is a valid need for that at times. However, I think it's quite a different thing. a semver number describes the nature of a current change, but the special cases 0/1 thing is about expectations of future change.

If you really want to indicate stability, do something like this: https://github.com/dominictarr/stability (I didn't make this up, this is how node.js indicates the stability of the core modules)

[DamonOehlman]

@dominictarr Thanks for pointing me to that thread, it's a goldmine of conversation around the topic. I think based on that thread the special meanings for pre 1.0 release should definitely be dropped.

[rvagg]

Personally I want to do away with the notion that "0" means anything special, we've invested too much in it and it's complicated our algorithms on this stuff. "pre-release" is something you should signal via other means, not by a semantic version number IMO.

[nrn]

Essentially in semver 0.0.x means no promise of bug fixes without api changes, 0.1.x means some bugs will be fixed without api changes, but the api may change drastically/often, and 1.x.x implies that api changes will be thoughtfully considered before being made.

What people mean by 0.1.x and 1.x.x and when it's ready to for production use or not is very nebulous and confusing. Most instances of 0.x.x should be x.x.0, and are not out of irrational self doubt, a fear of commitment and/or large numbers, or a feeling that they are signaling a project that they wish to keep working on is done.

However I still want a replacement for 0.0.x. Meaning this is an experiment, I have no intention of fixing your bugs, or holding some kind of api compatibility as I develop it. Tests are probably absent or lacking, and I don't care, because I'm still exploring the problem. You can use a version of this at your own risk, but the next release my be completely different and if you want to improve the old one fork it and have at.

I'm not sure semver's 0.0.x is a good way to say that, and it certainly makes range operators confusing if you want to support that idea. But not having that idea leaves no way to tell if 10.0.0 is the start of a new major supported release, or if it's the 10th crazy experiment to solve a problem. Maybe that distinction is too much to ask out of a version number?

[DamonOehlman]

Maybe that distinction is too much to ask out of a version number?

Yes, I think it probably is.

[dominictarr]

@nrn I've often seen people use this argument for the 0 range, that you'd end up with a very high major number, but in practice I do not think this actually happens.

Personally, I have written about 350 modules on npm over the course of several years. I do not hesitate to bump the major version, even removing a tiny thing, if it's technically a breaking change to the public api then I bump the major no matter how minor it is. In all the time, the highest major version I have got to is 7. I mainly write modules, for framworks maybe it's a different pattern.

Normally a major bump is because you are removing a dumb idea, or because you have thought of a different way to do a thing. "crazy experiments" tend to be completely new modules, not revisions to existing modules.

That applies to modules, if you have a framework or product that has a version numbers you may want to completely change what it is without changing the name, so that the "market share" that the product has achived stays attached. to be honest, I don't really like this, but it happens.

[Raynos]

In all the time, the highest major version I have got to is 7

Out of 400 modules, the highest I have is 9. my module dom-delegator has a global cache built into it, every time i change it subtly i have to bump the major to cache bust the global cache.

The next highest is like 5.

"crazy experiments" tend to be completely new modules, not revisions to existing modules.

:+1: