Certainly making a distinction between an architectural change/rewrite is important for many reasons. But I don't think it's a distinction we need to split out in the version number. Developers are more inclined to be able to use out-of-bound information than the program, for example, we understand "The code rewrite happened in version 4, and again in 5." To the application that's depending on the library, it doesn't care. All it cares is that it's not compatible with anything past 2.
I'd also argue it teaches people that, since 0.4.0 can potentially mean a breaking change, so could 1.1.0 (even though it doesn't). I don't want to give this impression. Perhaps ideally we would use four segments, "rewrite.major.minor.patch". On Thursday, September 20, 2012 11:52:31 AM UTC-7, Tim Caswell wrote: > > 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 <[email protected]<javascript:>> > 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 > > <[email protected]<javascript:>> > 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 [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
