For what it's worth, I see the value in using all three numbers to their fullest potential as the spec describes.
Also I explained my usage of node-style semver incorrectly and I apologize. My personal standard is I bump the last digit for both bug fixes and feature additions. Basically any change that won't break any code that depends on my library. I bump the middle number when I make a breaking change. So basically it's like the official semver except the first digit is 0 forever (nearly) and the last two are merged together. So the only missing feature is you can't tell the difference between a bug-fix release and a release that adds a new feature. Honestly this isn't super important to me. I always do my dependencies in the form "~0.2.3" and npm will match >= 0.2.3 and < 0.3.0. I depend on bugfixes and features present in 0.2.3 and am ok with getting any new features or bug fixes as long as it doesn't break my app. In the context of shared libraries this is a good thing. If feature additions were the middle digit and the first digit was breaking changes then people would either always match ~2.3 ignoring the last digit or ~2.3.5 and be locked to a certain set of features. For common libraries that are shared among several modules, this would cause duplication. By merging the feature addition digit with the bugfix digit the first digit is freed for major changes which is also useful. So the question is, which is more valuable? Being able to mark architectural changes or being able to tell feature additions apart from bug fixes. I think we all agree it's a good thing to be able to get bug fixes automatically without pulling in API breaking changes. But only two digits are required for that. As far as node itself, I have no say in how it's numbered and I understand it's system, so it's fine by me. As a linux user I'm used to the platform using different numbering systems than libraries. On Thu, Sep 20, 2012 at 1:37 PM, Karl Tiedt <kti...@gmail.com> wrote: > By this formula, Node has been 1.0+ since day one and never broken > backwards compatibility... Its understandable that young projects > hover below 1.0 in order to get a more throughly designed API in place > (and maybe fix/remove API kinks that were bad ideas at one point in > time)... but some would say that 3+ years is kinda pushing that safety > net for such a largely used project... > > Essentially anyone familiar with semver would be leery of using Node > for a large scale application with the lack of guarantee in backwards > compatibility (or they should be without better explanation of the > "Node way" of doing things). > > -Karl Tiedt > > > On Thu, Sep 20, 2012 at 1:24 PM, Tim Caswell <t...@creationix.com> wrote: > >> 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. >> > > -- > 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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
