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.html#version differently. 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 [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
