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 < > [email protected] <javascript:>> 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.**html#version<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<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 >>> nodejs+un...@**googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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]<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
