4 ms·

I am concerned the primary purpose of this being on the frontpage is shaming someone. I'm a big fan of semver, but I also test whenever I do a rm Gemfile.lock;

by hawkice 12y ago

I am concerned the primary purpose of this being on the frontpage is shaming someone. I'm a big fan of semver, but I also test whenever I do a rm Gemfile.lock; bundle install (I've only managed a fairly small nodejs app in production, but I'd be surprised if people really don't test something like that). So he did something we think is bad -- but plenty of beginning engineers do this all the time, and while the discussion on github is appropriate, I'm not sure it belongs here on HN. People shouldn't be afraid of making something useful (as underscore is) because of the potential for extremely public shaming.

abritishguy 12y ago
This is the most depended upon node module on npm, this is not some beginner engineer - I think this belongs here.
- hawkice 12y ago
  If the purpose is to alert people to perhaps subtle bugs in their code, then clearly it's relevant to the engineers here. But if your point is that we should publicly highlight mistakes (or things we don't like) in packages because we expect people to do better... then I guess I should step out of this conversation. I don't want to talk highschool about someone building cool things.
  - deleted 12y ago
    [deleted]
  - akerl_ 12y ago
    The connection between a project's developers and its community is noteworthy and worth discussing. As a developer, how you treat your user base is relevant, and has a real impact on the value of the thing you have produced. We have successful projects whose leaders vary wildly in style, from Linus's approach to kernel development to projects that delegate final code control to community contributors. Talking about the human elements that factor in to technology has merit; talking about the best ways to handle a project's community has merit. It's not "talk[ing] highschool".
- rubiquity 12y ago
  We could also submit a link to your issue on GitHub with the title "Engineer Mindlessly Updates Dependencies and Deploys Without Testing, Shocked to Learn Application Doesn't work."
  - abritishguy 12y ago
    I started a new repo and wanted to know why several of the dependencies were not working, only way to fix it was to manually change the underscore version number in these dependencies - obviously you wouldn't just push an update to production without testing it.
  - grayclhn 12y ago
    I think you'd find that it falls off the front page pretty quickly.
tedunangst 12y ago
Yes. Not that I had any plans to write node modules, but I sure as fuck don't want to now, lest somebody discover my work and start using it and then telling me how I need to do things.
- iends 12y ago
  https://www.npmjs.org/browse/depended https://www.npmjs.org/browse/depended _ is the most depended on node.js module. Maintainer, Ashkenas, introduced breaking changes. By default npm will pull down these changes without prompting because it was designed to follow semver. Maybe npm is at fault. Maybe it's Ashkenas. However, Ashkenas knows his change is going to break people and just doesn't care.
  - tedunangst 12y ago
    Did the same thing not happen with 1.6? And 1.5? Who thought 1.7 would be different?
  - __david__ 12y ago
    Or perhaps the fault lies with the people who update their dependencies blindly and then don't run tests. Not locking your dependencies down is a recipe for breakage.
    - iends 12y ago
      I suppose I shouldn't start new projects, either?
      - __david__ 12y ago
        How does that follow?
        iends 12y ago
        When you started a new project and pulled down new packages, all the packages that depended on underscore functionality that changed were broken because of this change. That's because NPM makes assumptions about major/minor versions and those packages pulled down the incompatible version. You can suggested that every package on npm vender their own dependencies, but in practice nobody does this because npm is known to make these assumptions.
akerl_ 12y ago
The larger discussion about whether or not package maintainers have a responsibility to minimize user frustration at the cost of their own opinions and practices is worthwhile. If I'm the author of an unpopular module, where I am the sole user, and I don't like semantic versioning or some other facet of package management, I don't follow it. Should I be expected to change my stance just because other people begin using my project? At what point is my project's community large enough that maintaining a healthy ecosystem involves sharing some control over the practices with that community? It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. Using that would be the height of insanity, as noted in the issue thread, because all libraries would need to update their dependencies and re-release with every Underscore-semver release, due to dependency version conflicts.
- rubiquity 12y ago
  > It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. What exactly about Jeremy Ashkenas makes you think this was done as a way to troll people? He still took a lot of time to make release notes and note all of the changes.
  - abritishguy 12y ago
    A maintainer did that.
    - krebby 12y ago
      Yup. I'm the contributor who wrote that pull for the release. You can see the original here https://github.com/jashkenas/underscore/pull/1799 https://github.com/jashkenas/underscore/pull/1799
  - akerl_ 12y ago
    I was referring specifically to the underscore-semver package, not the Underscore project as a whole. Using it in actual projects isn't feasible in any way, because it would require that your project and any project you depend on that also depends on underscore-semver specify the exact same version, or else we're back with the same problem as before. And since you won't be a package maintainer for everything your depend on in most cases, that isn't feasible. He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.
mmanfrin 12y ago
I think the problem is that it completely halts development of anything that uses a module that uses underscore (or even a module that uses a module that uses underscore, ad infinitum) since many modules have their dependencies written in such a way that npm will install 1.7, despite it not being compatible. This seems important enough to be something of a public-shaming. edit: Please comment saying why you disagree, rather than simply downvoting.
- gojomo 12y ago
  "Public shaming" of someone who's been as productive and generous with his open-source work as Ashkenas is never appropriate. Respectfully disagree on the particulars, sure, but don't imply that someone who's given you a gift now owes you extra work, when their own design sense – the same thing that created the shared bounty – guides them otherwise. People should also consider that authors of popular projects are inundated with support requests and demands for their time, and have to set some boundaries on their efforts, which may appear callous to outsiders. If his boundary here is not wanting to embrace Semantic Versioning, respect it, and fork/migrate/workaround rather than whine/shame/guilt.
iends 12y ago
Sadly, Jeremy Ashkenas is not a beginning engineer. He's just acting like one (or just trolling and wants everybody to switch to lodash).
kaoD 12y ago
Well, I'm glad this got to frontpage. I don't know if the purpose was shaming someone (it didn't even cross my mind) but it made me reflect on how my versioning affects others. I knew this was going to happen when NPM went from default ~ in dependencies (update only patches) to ^ (update minor versions). In fact, I changed my default back to ~ out of fear this would happen.

by hawkice 12y ago

abritishguy 12y ago

This is the most depended upon node module on npm, this is not some beginner engineer - I think this belongs here.

hawkice 12y ago
If the purpose is to alert people to perhaps subtle bugs in their code, then clearly it's relevant to the engineers here. But if your point is that we should publicly highlight mistakes (or things we don't like) in packages because we expect people to do better... then I guess I should step out of this conversation. I don't want to talk highschool about someone building cool things.
- deleted 12y ago
  [deleted]
- akerl_ 12y ago
  The connection between a project's developers and its community is noteworthy and worth discussing. As a developer, how you treat your user base is relevant, and has a real impact on the value of the thing you have produced. We have successful projects whose leaders vary wildly in style, from Linus's approach to kernel development to projects that delegate final code control to community contributors. Talking about the human elements that factor in to technology has merit; talking about the best ways to handle a project's community has merit. It's not "talk[ing] highschool".
rubiquity 12y ago
We could also submit a link to your issue on GitHub with the title "Engineer Mindlessly Updates Dependencies and Deploys Without Testing, Shocked to Learn Application Doesn't work."
- abritishguy 12y ago
  I started a new repo and wanted to know why several of the dependencies were not working, only way to fix it was to manually change the underscore version number in these dependencies - obviously you wouldn't just push an update to production without testing it.
- grayclhn 12y ago
  I think you'd find that it falls off the front page pretty quickly.

tedunangst 12y ago

Yes. Not that I had any plans to write node modules, but I sure as fuck don't want to now, lest somebody discover my work and start using it and then telling me how I need to do things.

iends 12y ago
https://www.npmjs.org/browse/depended https://www.npmjs.org/browse/depended _ is the most depended on node.js module. Maintainer, Ashkenas, introduced breaking changes. By default npm will pull down these changes without prompting because it was designed to follow semver. Maybe npm is at fault. Maybe it's Ashkenas. However, Ashkenas knows his change is going to break people and just doesn't care.
- tedunangst 12y ago
  Did the same thing not happen with 1.6? And 1.5? Who thought 1.7 would be different?
- __david__ 12y ago
  Or perhaps the fault lies with the people who update their dependencies blindly and then don't run tests. Not locking your dependencies down is a recipe for breakage.
  - iends 12y ago
    I suppose I shouldn't start new projects, either?
    - __david__ 12y ago
      How does that follow?
      - iends 12y ago
        When you started a new project and pulled down new packages, all the packages that depended on underscore functionality that changed were broken because of this change. That's because NPM makes assumptions about major/minor versions and those packages pulled down the incompatible version. You can suggested that every package on npm vender their own dependencies, but in practice nobody does this because npm is known to make these assumptions.

akerl_ 12y ago

The larger discussion about whether or not package maintainers have a responsibility to minimize user frustration at the cost of their own opinions and practices is worthwhile. If I'm the author of an unpopular module, where I am the sole user, and I don't like semantic versioning or some other facet of package management, I don't follow it. Should I be expected to change my stance just because other people begin using my project? At what point is my project's community large enough that maintaining a healthy ecosystem involves sharing some control over the practices with that community? It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. Using that would be the height of insanity, as noted in the issue thread, because all libraries would need to update their dependencies and re-release with every Underscore-semver release, due to dependency version conflicts.

rubiquity 12y ago
> It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. What exactly about Jeremy Ashkenas makes you think this was done as a way to troll people? He still took a lot of time to make release notes and note all of the changes.
- abritishguy 12y ago
  A maintainer did that.
  - krebby 12y ago
    Yup. I'm the contributor who wrote that pull for the release. You can see the original here https://github.com/jashkenas/underscore/pull/1799 https://github.com/jashkenas/underscore/pull/1799
- akerl_ 12y ago
  I was referring specifically to the underscore-semver package, not the Underscore project as a whole. Using it in actual projects isn't feasible in any way, because it would require that your project and any project you depend on that also depends on underscore-semver specify the exact same version, or else we're back with the same problem as before. And since you won't be a package maintainer for everything your depend on in most cases, that isn't feasible. He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.

mmanfrin 12y ago

I think the problem is that it completely halts development of anything that uses a module that uses underscore (or even a module that uses a module that uses underscore, ad infinitum) since many modules have their dependencies written in such a way that npm will install 1.7, despite it not being compatible. This seems important enough to be something of a public-shaming. edit: Please comment saying why you disagree, rather than simply downvoting.

gojomo 12y ago
"Public shaming" of someone who's been as productive and generous with his open-source work as Ashkenas is never appropriate. Respectfully disagree on the particulars, sure, but don't imply that someone who's given you a gift now owes you extra work, when their own design sense – the same thing that created the shared bounty – guides them otherwise. People should also consider that authors of popular projects are inundated with support requests and demands for their time, and have to set some boundaries on their efforts, which may appear callous to outsiders. If his boundary here is not wanting to embrace Semantic Versioning, respect it, and fork/migrate/workaround rather than whine/shame/guilt.

iends 12y ago

Sadly, Jeremy Ashkenas is not a beginning engineer. He's just acting like one (or just trolling and wants everybody to switch to lodash).

kaoD 12y ago

Well, I'm glad this got to frontpage. I don't know if the purpose was shaming someone (it didn't even cross my mind) but it made me reflect on how my versioning affects others. I knew this was going to happen when NPM went from default ~ in dependencies (update only patches) to ^ (update minor versions). In fact, I changed my default back to ~ out of fear this would happen.