Perhaps this is how it has come to be used, but unfortunately "young and growing" doesn't tell me anything useful about a project once I begin using it. Nor is "architectural change" versus "breaking change" a distinction that an application cares about.
Also if you use the minor version number to mean some sort of breakage, then you have no way of indicating that your application depends on a particular feature. Maybe a dependency on some new syntax sugar was introduced in 1.3.0, then you say your application depends on "~1.3". If you want to tell an application developer something *actually useful*, tell us when you break your public API. This isn't hard to do, you just have to break the notion that the major version number means anything about maturity. On Thursday, September 20, 2012 11:24:42 AM UTC-7, Tim Caswell wrote: > > My experience with the node community has been that we love semver, > but have a slightly different definition than what's on the website. > > If an npm module release is a bug-fix then the last digit is > incremented. If it's a API breaking change, then the middle digit is > incremented and the last digit is reset. If it's an architectural > change then the first digit it adjusted. Versions starting with > 0.x.y simply mean the project is young and growing. To convert > node-community-style semver numbers to "official" semver numbers, use > this table. > > 0.0.x -> 0.0.x > x.y.z -> (x + 1).y.z > > So 0.3.14 would be 1.3.14 and 0.0.14 would stay 0.0.14. > > Should we *force* everyone in the community to change our numbering > scheme to match what's on the website? I don't think so. Node has a > long history of not following existing standards strictly. > > Feel free to evangelize it and explain why it's better, but it's > dishonest to say that our de-facto system is worthless simply because > it's different. That kind of approach won't convince many people I'm > afraid. > > On Thu, Sep 20, 2012 at 1:16 PM, Mark Hahn <[email protected] <javascript:>> > wrote: > >> I think what semver asks is very reasonable > > > > Maybe. I'm just saying the odds of it's requirements being widely > adopted > > are slim to none. I don't think many developers have noticed any > problem > > using 0.x. > > > > I shouldn't be so negative though. Feel free to evangelize. I'll shut > up. > > > > > > On Thu, Sep 20, 2012 at 11:10 AM, Austin William Wright > > <[email protected] <javascript:>> wrote: > >> > >> If the API has not settled yet, then wouldn't that mean the API is not > >> stable? > >> > >> I think what semver asks is very reasonable: Tell us when you break > >> reverse compatibility. To do this, you can't use 0.x.x. > >> > >> On Thursday, September 20, 2012 12:52:44 AM UTC-7, Mariusz Nowak wrote: > >>> > >>> Austin, version v0.x doesn't mean that project is not *stable*, in my > >>> point of view everything published on npm should be stable (unstable > should > >>> just stay on github, or be published under different dedicated minor > >>> version, like node does: even numbered stable, odd numbered > experimental) > >>> > >>> Version v0.x just means that's it's API has not settled yet and it can > >>> change breaking backwards compatibility. It's exactly the reason why > Node.js > >>> is not yet 1.x, and it's up to semver rules. > >>> > >>> On Thursday, September 20, 2012 3:43:31 AM UTC+2, Austin William > Wright > >>> wrote: > >>>> > >>>> I've noticed that quite a lot of Node.js packages are tagging version > >>>> number zero for all their releases: 0.4.0, 0.9.9, 0.0.1, 0.27.4, etc > (to > >>>> pick from packages that I use). It's as if people think that if the > program > >>>> is not fully feature-complete, they shouldn't release version 1.0.0. > >>>> > >>>> You need not feel this way! Semver < > http://semver.org/spec/v1.0.0.html> > >>>> exists so that, in addition to providing a unique ID for each > release, we > >>>> can infer some basic facts about the compatibility of the release, in > >>>> comparison to other releases. It doesn't mean your code has all the > features > >>>> you want, it doesn't mean it has any standard of quality, it doesn't > even > >>>> mean "beta" or "production-ready". All semver asks you to do is (1) > tell us > >>>> when you break reverse-compatibility of your public API, (2) tell us > when > >>>> you release a new feature, and (3) tell us when you patch a > particular bug. > >>>> If you use major version zero, we lose all of this information. By > >>>> definition, major version zero carries no semantics whatsoever. ~0 > (major > >>>> version zero) is supposed to be used for internal development and > quick > >>>> iteration where nearly every change breaks of the public API. > However, if > >>>> you're releasing software publicly, your users expect some stability > in your > >>>> public API. The series of releases that are stable against one > another > >>>> should carry the same nonzero major revision number, like "1.x.x". If > you > >>>> accidentally make a change that breaks, then just release a bugfix > release > >>>> for the breakage, and optionally release a new major version that > carries > >>>> the breakage. > >>>> > >>>> If you don't identify when you break your public API, then developers > >>>> have to manually figure out which releases are breaking, and which > are safe > >>>> to upgrade to. We may have to carefully examine changelogs and > create and > >>>> run unit tests. This wastes developer time. It's also makes it hard > to > >>>> future-proof releases: If I know that 1.0.0 is compatible with my > >>>> application, then so should 1.3.1, and any ~1 version. Unit tests are > not a > >>>> replacement for the major version number: When picking an appropriate > >>>> package version to update to, developers (or automated programs) do > not have > >>>> access to changelogs or the source code to run unit tests on (nor > should > >>>> they). (There's also the corollary, version numbers are not a > replacement > >>>> for unit tests, of course.) Nor can per-module or per-function > version > >>>> numbers replace a package-wide version number. These sub-versions may > be a > >>>> good idea, but they do not tell us anything about which version of a > >>>> package, something installed as a coherent whole, should be > installed. > >>>> > >>>> Node.js itself is still releasing major version zero. This is > >>>> unacceptable for all the same reasons. Node.js should be releasing > 1.0.0 > >>>> right now (and actually, a long while ago). Then, when a new feature > is > >>>> added (major change of an internal library, new core library, etc), > >>>> increment the minor version number. If it breaks > reverse-compatibility > >>>> (crypto finally starts using buffers, say), increment the major > revision > >>>> number. It might be a minor breakage, in which case we can run all > our tests > >>>> and ensure it's no change that breaks the program, and then we can > say "My > >>>> program is compatible with Node.js ~2 as well as ~1.2". There is > nothing so > >>>> special about any feature like libuv that its release can't be marked > with > >>>> 2.0.0 instead, it's just a number that tells us something broke. It > doesn't > >>>> mean it's conforming to any release schedule, it doesn't mean it's > feature > >>>> complete. > >>>> > >>>> Having "stable" and "unstable" branches is fine for Git development, > >>>> however having stable/unstable version numbers is not: The stable > branch > >>>> should get it's own major version number. Unstable branches would be > release > >>>> candidates for the next major version number: 4.0.0-a1, 4.0.0-a4, > 4.0.0-rc1, > >>>> etc. (Of course this numbering scheme should be avoided in production > for > >>>> all the same reasons, it doesn't mean anything, it's just a period of > rapid > >>>> iteration and API breakage.) > >>>> > >>>> It's just a number, numbers are cheap. If you need to make a dozen > >>>> consecutive, breaking releases, then simply number them accordingly, > 3.0.0 > >>>> through 14.0.0. That's how semver works! > >>>> > >>>> Who else has encountered problems with packages breaking the semantic > >>>> versioning scheme and reverse compatibility? > >>>> > >>>> Austin Wright. > >> > >> -- > >> Job Board: http://jobs.nodejs.org/ > >> Posting guidelines: > >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > >> You received this message because you are subscribed to the Google > >> Groups "nodejs" group. > >> To post to this group, send email to [email protected]<javascript:> > >> To unsubscribe from this group, send email to > >> [email protected] <javascript:> > >> For more options, visit this group at > >> http://groups.google.com/group/nodejs?hl=en?hl=en > > > > > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
