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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kill the special pre-1.0.0 meaning for ^ & ~ #2

Closed
rvagg opened this Issue Jun 17, 2014 · 11 comments

Comments

Projects
None yet
5 participants
@rvagg
Copy link

rvagg commented Jun 17, 2014

馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟

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

馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟 馃敟

@rvagg rvagg changed the title :fire: :fire: Kill the special pre-1.0.0 meaning for ^ & ~ :fire: :fire: Kill the special pre-1.0.0 meaning for ^ & ~ Jun 17, 2014

@DamonOehlman

This comment has been minimized.

Copy link
Owner

DamonOehlman commented Jun 17, 2014

@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

This comment has been minimized.

Copy link
Owner

DamonOehlman commented Jun 17, 2014

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

This comment has been minimized.

Copy link

rvagg commented Jun 17, 2014

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

This comment has been minimized.

Copy link
Owner

DamonOehlman commented Jun 17, 2014

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

This comment has been minimized.

Copy link

dominictarr commented Jun 17, 2014

@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... dominictarr/semver-ftw#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

This comment has been minimized.

Copy link
Owner

DamonOehlman commented Jun 17, 2014

@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

This comment has been minimized.

Copy link

rvagg commented Jun 18, 2014

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

This comment has been minimized.

Copy link

nrn commented Jun 20, 2014

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

This comment has been minimized.

Copy link
Owner

DamonOehlman commented Jun 20, 2014

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

Yes, I think it probably is.

@dominictarr

This comment has been minimized.

Copy link

dominictarr commented Jun 20, 2014

@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

This comment has been minimized.

Copy link

Raynos commented Jun 20, 2014

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.

馃憤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment