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.html#version differently. Therefore, it's my > responsibility to: > Understand how my dependencies define versions. > Lock versions down for production. > Upgrade explicitly and with cause. > 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 [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 -- 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
