> 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 < [email protected]> 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 <diamon...@users.* >> *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#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<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] > 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
