Well then you have no need for version numbers at all, what are you complaining about?
Some of us, however, do rely on upgrading packages. Some of use multiple packages that require() the same module, we need a way to resolve which package is mutually compatible. You can't make broad assumptions like "never upgrade packages". That doesn't solve the fundamental problem. On Thursday, September 20, 2012 5:45:03 PM UTC-7, Mark Hahn wrote: > > > 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] <javascript:>> 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]<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
