> 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]> 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] > 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
