Matt, Ian, It was once said, in the Long Ago Days of the Time Before,
> Another option might be to let authors add an "enginesStrict" boolean > flag in their package.json which would say, "No, seriously, this WILL > NOT WORK except with the specified versions, so don't even try to use > it." How does that strike you? Then it would be a warning, unless the author says, "No, srsly, I really mean it," in which case, it'd use the current behavior. (And please don't do that for 0.8.x, because it's probably just going to be annoying in a few months, like how "0.6.x" is now.) On Wed, Jun 27, 2012 at 2:28 PM, Matt <[email protected]> wrote: > How about this fix for npm: > > if (node version > package's "engines" tag), then don't track back to look > for older versions. > > And specifically, when tracking back to look for older versions, only look > at older versions that HAVE the "engines" tag present, not ones lacking it. > > On Wed, Jun 27, 2012 at 4:33 PM, Ian Young <[email protected]> wrote: >> >> I share Matt's concern. I'd be bummed if I wanted to release a new version >> of a module that depended on 0.8 features, but doing so would mean most of >> my users on 0.6 got a broken version installed by default with only a >> warning to dissuade them. Especially if there were perfectly good older >> versions sitting in npm that worked on 0.6. >> >> Maybe npm could issue a warning on maximum version failures, but keep the >> old behavior on minimum version failures. That's getting kinda complex, >> though. >> >> I wonder if this isn't better solved by guiding the community towards >> removing upper limits from engines in all but the most specific cases? >> >> >> On Wednesday, June 27, 2012 1:22:39 PM UTC-7, Matt Sergeant wrote: >>> >>> I'm -1 for reducing it to a warning. By doing that you're taking the >>> opposite assumption, that the person who wrote the package doesn't know what >>> he/she's doing. What if the package uses domains and puts in engines: >>> ">=0.8.0" ? By reducing it to a warning you're letting people's code fail at >>> runtime instead of at install time. >>> >> -- >> 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 -- 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
