Received: by 10.205.127.71 with SMTP id gz7mr402803bkc.7.1348188303317; Thu, 20 Sep 2012 17:45:03 -0700 (PDT) X-BeenThere: nodejs@googlegroups.com Received: by 10.204.129.72 with SMTP id n8ls503705bks.0.gmail; Thu, 20 Sep 2012 17:44:47 -0700 (PDT) Received: by 10.204.146.68 with SMTP id g4mr385456bkv.4.1348188287337; Thu, 20 Sep 2012 17:44:47 -0700 (PDT) Received: by 10.204.146.68 with SMTP id g4mr385455bkv.4.1348188287299; Thu, 20 Sep 2012 17:44:47 -0700 (PDT) Return-Path: Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by gmr-mx.google.com with ESMTPS id 23si589991bku.1.2012.09.20.17.44.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 17:44:47 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.217.182 is neither permitted nor denied by best guess record for domain of m...@hahnca.com) client-ip=209.85.217.182; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 209.85.217.182 is neither permitted nor denied by best guess record for domain of m...@hahnca.com) smtp.mail=m...@hahnca.com Received: by mail-lb0-f182.google.com with SMTP id gg13so5370618lbb.27 for ; Thu, 20 Sep 2012 17:44:47 -0700 (PDT) d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=yHcLienoMi9uL+8hir/o6fO0YeJbPTwUy7EYnG9cTpA=; b=a5xP6v7v4ey2HbgeaEiGkoYzvifNcaiI6DVpsrZULPCTpHT2Kfcd0uhHgEZJ/+Wvee 9EMdVfD+L7xoi7yIPGdRGkzOQxnWReelfVh18Jf5OY6Dd2n34zXGvZz5w3p32obBz25h h26xORSGCbAQGAGvcqDHLcijzpKhBHHv/IdP1oYDJtySY9pLqmwoTYNVBPA9pwwHi2GR y5Yk9pqjkMhROiMc187C84sATFFXbZJAXdcRAUtXvhCDz/xLEiko2KtQda7BMPi0pme2 Rt3kg4PJP+vdTg2NJWvtviQOyePFgYdkabEnEcGdbOnXGRSX4NdHm6I/vPwi6enCtIV4 ujqg== Received: by 10.112.17.131 with SMTP id o3mr1195217lbd.6.1348188286847; Thu, 20 Sep 2012 17:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.74.196 with HTTP; Thu, 20 Sep 2012 17:44:23 -0700 (PDT) X-Originating-IP: [68.5.117.177] In-Reply-To: <5a1bff4f-2a51-4c9c-a6e7-0d08e27a6a02@googlegroups.com> References: <1e8e7c53-0808-4439-9d48-d01f91b901bb@googlegroups.com> <81a5aa4f-ea03-415c-a411-1c91b5b81f77@googlegroups.com> <6ef70a98-2213-4341-a61e-d88667537425@googlegroups.com> <6e28e9de-4f5c-4b3b-94a2-eac7c51734b5@googlegroups.com> <5e187740-bd17-4fa0-af0a-2270812aad69@googlegroups.com> <5a1bff4f-2a51-4c9c-a6e7-0d08e27a6a02@googlegroups.com> From: Mark Hahn Date: Thu, 20 Sep 2012 17:44:23 -0700 Message-ID: Subject: Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero To: nodejs@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec554d330ed8a1104ca2b8b97 X-Gm-Message-State: ALoCoQkJug1FAvV7YkA31uGEXAOivQDJJKMuIMkJzSsfhkAJLXYWbEhQyWp2EUJhCdJmVu6gOPkV --bcaec554d330ed8a1104ca2b8b97 Content-Type: text/plain; charset=ISO-8859-1 > You want to update to the latest package that's compatible with your current version. I don't understand why you would want to do that. You are taking a risk for no reason. I only update when I need a feature or some bug is discovered. In either case I may need to change my code or may not. I don't really have any control over that. I said I was going to shut up and I didn't. I will try harder now. On Thu, Sep 20, 2012 at 5:38 PM, Austin William Wright < diamondma...@users.sourceforge.net> wrote: > I never said you need to trust the library developer, but that's no excuse > for them to mis-identify which versions are breaking, and which are stable. > > You want to update to the latest package that's compatible with your > current version. What's the easiest way to do that? I should not need to > trial-and-error releases to find a good, working one. > > On Thursday, September 20, 2012 5:26:10 PM UTC-7, Mark Hahn wrote: >> >> > developers should be able to identify at a glance which version is >> breaking, and which is not >> >> You sure have a lot of faith in the developers. I would never trust any >> version numbering scheme. When I need a new feature or a bug-fix I test >> the latest version. I don't even pay attention to version numbers. I >> can't imagine making any of my decisions based on version numbers. >> >> On Thu, Sep 20, 2012 at 5:00 PM, Austin William Wright > *sourceforge.net> wrote: >> >>> For production applications, having tests and maintaining dependencies >>> is a good idea. However I explained this isn't a replacement for the major >>> version number: >>> >>> (1) Not everyone is writing production applications. My own ~0 >>> application in production moves too fast for tests to be meaningful. >>> >>> (2) You should not require people to use trial and error to figure out >>> which release is compatible when updating dependencies, developers should >>> be able to identify at a glance which version is breaking, and which is >>> not, so we know which version to update to (I use Git submodules for this >>> task). >>> >>> >>> On Thursday, September 20, 2012 4:51:40 PM UTC-7, Chris Corbyn wrote: >>> >>>> I'll apply my same thinking under Rails/rubygems/bundler to node/npm. I >>>> don't ever look at version numbers of gems I use, or NPM modules now that >>>> I've started doing some node too. I install them, version control them and >>>> write tests. If my app works with the dependencies at the versions I >>>> installed, I don't need to care if the gem/npm module developer then starts >>>> hacking and making breaking changes in the main repo. My versions are >>>> frozen, until I decide to try updating them. When I update my dependencies, >>>> I run my tests. If the tests explode, I have two choices: 1. figure out >>>> what I need to change to get back up and running, or 2. lock the dependency >>>> to a version I know happens to work. >>>> >>>> I do tend to look at how responsive the developer is to issues/pull >>>> requests and how long it's been since the last commit, but that's more >>>> because I don't want to use an abandoned project. >>>> >>>> I don't really see how ongoing development of a dependency in your >>>> application is likely to cause any issues, provided you actually freeze >>>> versions. In Rails Gemfile.lock ensures new developer joining the team have >>>> all the same versions. In Node, installing the modules locally works fine >>>> too. And make sure you have good test coverage. >>>> >>>> >>>> Il giorno 21/set/2012, alle ore 09:17, Michael Schoonmaker ha scritto: >>>> >>>> I don't disagree with you insofar as using something that *looks like *semver >>>> without *being *semver can be confusing. >>>> >>>> However, what I do disagree with is the attitude that we should change >>>> *common practice* because there is a similar-looking *standard*. Does >>>> that make sense? It's one thing to be confusing. It's something else >>>> entirely that *the ship has sailed*, and there are plenty of people on >>>> the deck having a great time. >>>> >>>> I'm relatively new to Node (on the order of almost a year instead of >>>> several), but I understand what npm version numbers entail, and I >>>> understand that it's *my *package.json that describes what version of >>>> each dependency I use. Just as two applications may use different >>>> versioning schemes altogether, so two package developers may interpret >>>> https://npmjs.org/doc/json.**htm**l#versiondifferently. Therefore, it's >>>> *my *responsibility to: >>>> >>>> 1. Understand how my dependencies define versions. >>>> 2. Lock versions down for production. >>>> 3. Upgrade explicitly and with cause. >>>> 4. Update my package.json accordingly. >>>> >>>> Schoon >>>> >>>> -- >>>> 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 nod...@googlegroups.com >>>> >>>> To unsubscribe from this group, send email to >>>> nodejs+un...@**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 nod...@googlegroups.com >>> To unsubscribe from this group, send email to >>> nodejs+un...@**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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > --bcaec554d330ed8a1104ca2b8b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A0You want to update to the latest = package that's compatible with your current version.=A0

I don't understand w= hy you would want to do that. =A0You are taking a risk for no reason. =A0

I only update when I need a feature or some bu= g is discovered. =A0In either case I may need to change my code or may not.= =A0I don't really have any control over that.

I said I was going to shut up and I didn't. =A0I will= try harder now.


On Thu, Sep 20, 2012 at 5:38 PM, Austin William = Wright <diamondma...@users.sourceforge.net>= wrote:
I never said you need to trust the library d= eveloper, but that's no excuse for them to mis-identify which versions = are breaking, and which are stable.

You want to update to the latest package that's compatib= le with your current version. What's the easiest way to do that? I shou= ld not need to trial-and-error releases to find a good, working one.

On Thursday, September 20, 2012 5:26:10 PM UTC-7, Mark Hahn wrote:>=A0developers should be able to ide= ntify at a glance which version is breaking, and which is not

You sure have a lot of f= aith in the developers. =A0I would never trust any version numbering scheme= . =A0When I need a new feature or a bug-fix I test the latest version. =A0I= don't even pay attention to version numbers. =A0I can't imagine ma= king any of my decisions based on version numbers.

On Thu, Sep 20, 2012 at 5:00 PM, Aust= in William Wright <diamon...@users.sourcefor= ge.net> wrote:
For production applications, having tests an= d maintaining dependencies is a good idea. =A0However I explained this isn&= #39;t a replacement for the major version number:

(1) Not everyone is writing production applications. My own = ~0 application in production moves too fast for tests to be meaningful.

(2) You should not require people to use trial and er= ror to figure out which release is compatible when updating dependencies, d= evelopers should be able to identify at a glance which version is breaking,= and which is not, so we know which version to update to (I use Git submodu= les for this task).


On Thursday, September 20, 2012 4:51:40 PM UTC-7, Chris Corbyn wrot= e:
I'll apply my same thinking under Rails/rubygems/bundler to node/n= pm. I don't ever look at version numbers of gems I use, or NPM modules = now that I've started doing some node too. I install them, version cont= rol them and write tests. If my app works with the dependencies at the vers= ions I installed, I don't need to care if the gem/npm module developer = then starts hacking and making breaking changes in the main repo. My versio= ns are frozen, until I decide to try updating them. When I update my depend= encies, I run my tests. If the tests explode, I have two choices: 1. figure= out what I need to change to get back up and running, or 2. lock the depen= dency to a version I know happens to work.

I do tend to look at how responsive the developer= is to issues/pull requests and how long it's been since the last commi= t, but that's more because I don't want to use an abandoned project= .

I don't really see how ongoing developme= nt of a dependency in your application is likely to cause any issues, provi= ded you actually freeze versions. In Rails Gemfile.lock ensures new develop= er joining the team have all the same versions. In Node, installing the mod= ules locally works fine too. And make sure you have good test coverage.


Il giorno 21/set/2012, alle ore 09:1= 7, Michael Schoonmaker ha scritto:

I don't disagree with you insofar as using something that look= s like semver without being semver can be confusing.

However, what I do disagree with is the attitude that we sho= uld change common practice because there is a similar-looking sta= ndard. Does that make sense? It's one thing to be confusing. It'= ;s something else entirely that the ship has sailed, and there are p= lenty of people on the deck having a great time.

I'm relatively new to Node (on the order of almost = a year instead of several), but I understand what npm version numbers entai= l, and I understand that it's my package.json that describes wha= t version of each dependency I use. Just as two applications may use differ= ent versioning schemes altogether, so two package developers may interpret = https= ://npmjs.org/doc/json.html#version differently. Therefore= , it's my responsibility to:
  1. Understand how my dependencies define versions.
  2. Lock v= ersions down for production.
  3. Upgrade explicitly and with cause.
  4. Update my package.json accordingly.
Schoon

--
Job Board: http://job= s.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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/nodejs?hl=3Den?hl=3De= n

--
Job Board: http://job= s.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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=3Den?hl=3Den

--
Job Board: http://job= s.nodejs.org/
Posting guidelines: https://github.com/joyent/node/w= iki/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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=3Den?hl=3Den

--bcaec554d330ed8a1104ca2b8b97--