12 ms·

Fix the versioning

115 points by abritishguy 12y ago

ascendantlogic 12y ago
It takes the same amount of effort to type "2.0.0" as it does "1.7.0" but the effects of this choice are obviously much larger. Why is it such a roadblock to not break everyone else's code?
- kalleboo 12y ago
  It sounds like the maintainers reasoning is "pretty much every version is going to break something somewhere"
  - sethammons 12y ago
    That is where I get lost. What is wrong with that?
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.
ocfx 12y ago
Well lo-dash is better anyways, dunno why people are still using underscore
seliopou 12y ago
The only major version bump that matters is the one from 0 to 1. After that, the project is better served if its maintainers do not fetishize major version numbers, or any version numbers for that matter, and realize that they're there to facilitate automation, not to satisfy some sense of human aesthetics.
gojomo 12y ago
The title-as-submitted ("Underscore.js author breaks 100s of modules because of a disliking of semver") is unnecessarily personalizing and editorializing. I'd suggest a title of just the facts: "Underscore.js 1.7.0 breaks modules by rejecting semantic versioning". (The native title, "Fix the versioning", contains insufficient detail to convey either the important warning-to-Underscore-users nor reflect the issues discussed.) This issue highlights an interesting philosophical split. I suspect the same minimalist, intentional aesthetic that has made Ashkenas's projects so beloved equally drives his dislike of version-inflation, whatever its convenience is to downstream systems on autopilot.
- abritishguy 12y ago
  I agree, looks like a mod has changed it anyway.
- kudu 12y ago
  > The native title, "Fix the versioning", contains insufficient detail to convey either the important warning-to-Underscore-users nor reflect the issues discussed. Incidently, this is the title the mods chose. Can anyone guess how many spots the link dropped on the front page after that change?
thinkbohemian 12y ago
1) Semver is hard. I've got publicly used libraries with millions of downloads and sometimes people use it in ways I don't expect and this results in breaking backwards compatibility. Most large projects aren't, or can't be true semver. Take for example Rails. This is a great discussion over an area over why breaking semver may be better than keeping it in one case: https://github.com/rails/rails/issues/16497 https://github.com/rails/rails/issues/16497 2) Breaking semver sucks, and I go hulk rage mad when my shit breaks.
- abritishguy 12y ago
  Totally agree, however I feel there is a difference between choosing to break semver for a specific reason rather than a complete disregard for it. Semver should be based upon the public API - if a dependent module is using undocumented stuff then they should pin the version down.
tylerlh 12y ago
This feels like an overly abrasive response that makes me seriously question whether using Underscore moving forward is a good idea. I really hate to say that because I think Jeremy's projects are awesome. This is the most depended on module on npm. Why are you so intent on alienating the package consumers? IMO, having a version 47.0.0 and such doesn't seem all that terrible to me, and is still just as human readable. Other groups are doing it and it's working just fine (ie Chrome).
- jessaustin 12y ago
  ...having a version 47.0.0 and such doesn't seem all that terrible to me... What would the effect of that be? Since few people are silly enough to use the ">=" operator in package.json, a popular package with that many "breaking" changes is effectively going to be pinned at 46 different points. I imagine we'd start to see some of the same entitled whinging we see exhibited here, but in the opposite direction. "Why do you have so many major releases? It means I have to re-release my packages constantly."
  - tylerlh 12y ago
    That's a fair point. I guess a better solution in my mind is teaching people to be more responsible with their package.json file and consumption of packages (ie reading changelogs), but that's not jashkenas' problem, nor should it be.
    - jessaustin 12y ago
      Actually I think he's done quite a bit of teaching along those lines in the last three days. Several students seem unhappy with the lesson...
jessaustin 12y ago
It takes a certain chutzpah to leave the sort of comments one sees on this issue and the similar one for Backbone. The author hasn't made a secret of his versioning policy. If you have a broken module, you shouldn't have used [EDIT: actually "~" would have been fine] "^" or (my favorite) ">=" as a semver operator when depending on this module on which you depend for free. Anyway, with a decent test suite, surely a modicum of (automated) testing has already identified the pinning that should take place?
- abritishguy 12y ago
  >The author hasn't made a secret of his versioning policy. No one is going to see that unless they go looking for it though >you shouldn't have used "~", "^" That is how the npm ecosystem works, and in any case the issue arose from dependencies that in turn depended on underscore and thus are not under my direct control. > Anyway, with a decent test suite, surely a modicum of (automated) testing has already identified the pinning that should take place? My particular issue is in a new project I could not install several dependencies as npm downloaded the newest compatible version which was supposedly 1.7.0 - the only way to fix this is to manually create a lock file. >you depend for free. True, and I'm tremendously grateful for all the work that has gone into it and it would be a massive shame if that work was for nothing if a continued disregard for semver forces people to switch to lodash.
  - jessaustin 12y ago
    ...dependencies that in turn depended on underscore... Do you imagine that the maintainers of all these dependencies are going to catch any fraction of the hell that jashkenas seems to be catching for this? It's just as much their fault as it is his. Why don't they pin and test?
    - abritishguy 12y ago
      Because that is not the convention in the ecosystem - npm mandates the use of semver - if you follow it this can't happen. If you do what you say and pin it down to an exact version then you would have to release an update every week consisting of just a version bump.
krebby 12y ago
See also https://github.com/jashkenas/underscore/issues/1684 https://github.com/jashkenas/underscore/issues/1684
jashkenas 12y ago
If the asshole responsible for this mess can chime in for a moment ;) I figured that it was worth a bit of a longer explanation (cross-posted from https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e) --- Spurred by this thread, here's is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it. For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0. But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/ http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us. SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that will be affected by the change, the severity of the change (Is it easy to fix my code? Or do I have to rewrite everything?) — into a single number. And unsurprisingly, it's impossible for that single number to contain enough meaningful information. If your package has a minor change in behavior that will "break" for 1% of your users, is that a breaking change? Does that change if the number of affected users is 10%? or 20? How about if instead, it's only a small number of users that will have to change their code, but the change for them will be difficult? — a common event with deprecated unpopular features. Semantic versioning treats all of these scenarios in the same way, even though in a perfect world the consumers of your codebase should be reacting to them in quite different ways. Ultimately, breaking changes are no fun, and we should strive to avoid them when possible. To the extent that SemVer encourages us to avoid changing our public API, it's all for the better. But to the extent that SemVer encourages us to pretend like minor changes in behavior aren't happening all the time; and that it's safe to blindly update packages — it needs to be re-evaluated. Some pieces of software are like icebergs: a small surface area that's visible, and a mountain of private code hidden beneath. For those types of packages, something like SemVer can be helpful. But much of the code on the web, and in repositories like npm, isn't code like that at all — there's a lot of surface area, and minor changes happen frequently. Ultimately, SemVer is a false promise that appeals to many developers — the promise of pain-free, don't-have-to-think-about-it, updates to dependencies. But it simply isn't true. Node doesn't follow SemVer, Rails doesn't do it, Python doesn't do it, Ruby doesn't do it, jQuery doesn't (really) do it, even npm doesn't follow SemVer. There's a distinction that can be drawn here between large packages and tiny ones — but that only goes to show how inappropriate it is for a single number to "define" the compatibility of any large body of code. If you've ever had trouble reconciling your npm dependencies, then you know that it's a false promise. If you've ever depended on a package that attempted to do SemVer, you've missed out on getting updates that probably would have been lovely to get, because of a minor change in behavior that almost certainly wouldn't have affected you. If at this point you're hopping on one foot and saying — wait a minute, Node is 0.x.x — SemVer allows pre-1.0 packages to change anything at any time! You're right! And you're also missing the forest for the trees! Keeping a system that's in heavy production use at pre-1.0 levels for many years is effectively the same thing as not using SemVer in the first place. The responsible way to upgrade isn't to blindly pull in dependencies and assume that all is well just because a version number says so — the responsible way is to set aside five or ten minutes, every once in a while, to go through and update your dependencies, and make any minor changes that need to be made at that time. If an important security fix happens in a version that also contains a breaking change for your app — you still need to adjust your app to get the fix, right? SemVer is woefully inadequate as a scheme that determines compatibility between two pieces of code — even a textual changelog is better. Perhaps a better automated compatibility scheme is possible. One based on matching type signatures against a public API, or comparing the runs of a project's public test suite — imagine a package manager that ran the test suite of the version you're currently using against the code of the version you'd like to upgrade to, and told you exactly what wasn't going to work. But SemVer isn't that. SemVer is pretty close to the most reductive compatibility check you would be able to dream up if you tried. If you pretend like SemVer is going to save you from ever having to deal with a breaking change — you're going to be disappointed. It's better to keep version numbers that reflect the real state and progress of a project, use descriptive changelogs to mark and annotate changes in behavior as they occur, avoid creating breaking changes in the first place whenever possible, and responsibly update your dependencies instead of blindly doing so. Basically, Romantic Versioning, not Semantic Versioning. All that said, okay, okay, fine — Underscore 1.7.0 can be Underscore 2.0.0. Uncle. (typed in haste, excuse any grammar-os, will correct later)
deleted 12y ago
[deleted]
QuantumChaos 12y ago
Can someone outline who the people arguing against Jeremy Ashkenas are? It would make a big difference if they were ordinary users, vs maintainers of other important libraries of pieces of software. While everyone deserves their say, this issue seems somewhat subjective, and a package maintainer shouldn't have to pay undue attention to individual users who don't necessarily represent the whole community.
shadeless 12y ago
I'm a bit surprised no one has mentioned FerVer(Fear-Driven Versioning) yet, it was made in an effort to fix exactly this kind of problem. [1] [1] https://github.com/jonathanong/ferver https://github.com/jonathanong/ferver
Lavinski 12y ago
This link (http://www.jongleberry.com/semver-has-failed-us.html http://www.jongleberry.com/semver-has-failed-us.html) was also posted on HN a while ago. HN: https://news.ycombinator.com/item?id=8154933 https://news.ycombinator.com/item?id=8154933
ricardobeat 12y ago
The blame for this falls squarely on NPM for replacing the default ~ (update patches) with ^ (update minor versions). The only reason for having automatic package updates in the first place is to receive bug and security patches. There is little gain in receiving 'minor' updates if you are not changing your code, and any serious project will end up freezing the dependency tree anyway.
- jessaustin 12y ago
  Is this ironic? https://github.com/npm/npm/releases/tag/v1.4.3 https://github.com/npm/npm/releases/tag/v1.4.3 [look at the patch number...]
eldude 12y ago
Simple, add an optional human significant "ultra" version (better name suggestions welcome) to indicate a philosophical version upgrade consistent with how major versions have historically been used (as marketing communications). E.g., 1.1.7.0 or 1.7.0 are equivalent. [Cross posted from the other thread: https://news.ycombinator.com/item?id=8244920 https://news.ycombinator.com/item?id=8244920]
deleted 12y ago
[deleted]
wprl 12y ago
It's really not that hard. If you have a lot of breaking changes, you probably shouldn't be at 1.x.x. If you need to deprecate something, add the extra features alongside and remove the deprecated features in the next major release. If you need to add something to code that is >= 1.x.x and you think it will need breaking changes, you should mark the feature as experimental in the documentation until it has stabilized. Semver works great for humans and robots if you put a smidgeon of planning and consideration into the process!

115 points by abritishguy 12y ago

It takes the same amount of effort to type "2.0.0" as it does "1.7.0" but the effects of this choice are obviously much larger. Why is it such a roadblock to not break everyone else's code?

kalleboo 12y ago
It sounds like the maintainers reasoning is "pretty much every version is going to break something somewhere"
- sethammons 12y ago
  That is where I get lost. What is wrong with that?

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.

ocfx 12y ago

Well lo-dash is better anyways, dunno why people are still using underscore

seliopou 12y ago

The only major version bump that matters is the one from 0 to 1. After that, the project is better served if its maintainers do not fetishize major version numbers, or any version numbers for that matter, and realize that they're there to facilitate automation, not to satisfy some sense of human aesthetics.

gojomo 12y ago

The title-as-submitted ("Underscore.js author breaks 100s of modules because of a disliking of semver") is unnecessarily personalizing and editorializing. I'd suggest a title of just the facts: "Underscore.js 1.7.0 breaks modules by rejecting semantic versioning". (The native title, "Fix the versioning", contains insufficient detail to convey either the important warning-to-Underscore-users nor reflect the issues discussed.) This issue highlights an interesting philosophical split. I suspect the same minimalist, intentional aesthetic that has made Ashkenas's projects so beloved equally drives his dislike of version-inflation, whatever its convenience is to downstream systems on autopilot.

abritishguy 12y ago
I agree, looks like a mod has changed it anyway.
kudu 12y ago
> The native title, "Fix the versioning", contains insufficient detail to convey either the important warning-to-Underscore-users nor reflect the issues discussed. Incidently, this is the title the mods chose. Can anyone guess how many spots the link dropped on the front page after that change?

thinkbohemian 12y ago

1) Semver is hard. I've got publicly used libraries with millions of downloads and sometimes people use it in ways I don't expect and this results in breaking backwards compatibility. Most large projects aren't, or can't be true semver. Take for example Rails. This is a great discussion over an area over why breaking semver may be better than keeping it in one case: https://github.com/rails/rails/issues/16497 https://github.com/rails/rails/issues/16497 2) Breaking semver sucks, and I go hulk rage mad when my shit breaks.

abritishguy 12y ago
Totally agree, however I feel there is a difference between choosing to break semver for a specific reason rather than a complete disregard for it. Semver should be based upon the public API - if a dependent module is using undocumented stuff then they should pin the version down.

tylerlh 12y ago

This feels like an overly abrasive response that makes me seriously question whether using Underscore moving forward is a good idea. I really hate to say that because I think Jeremy's projects are awesome. This is the most depended on module on npm. Why are you so intent on alienating the package consumers? IMO, having a version 47.0.0 and such doesn't seem all that terrible to me, and is still just as human readable. Other groups are doing it and it's working just fine (ie Chrome).

jessaustin 12y ago
...having a version 47.0.0 and such doesn't seem all that terrible to me... What would the effect of that be? Since few people are silly enough to use the ">=" operator in package.json, a popular package with that many "breaking" changes is effectively going to be pinned at 46 different points. I imagine we'd start to see some of the same entitled whinging we see exhibited here, but in the opposite direction. "Why do you have so many major releases? It means I have to re-release my packages constantly."
- tylerlh 12y ago
  That's a fair point. I guess a better solution in my mind is teaching people to be more responsible with their package.json file and consumption of packages (ie reading changelogs), but that's not jashkenas' problem, nor should it be.
  - jessaustin 12y ago
    Actually I think he's done quite a bit of teaching along those lines in the last three days. Several students seem unhappy with the lesson...

jessaustin 12y ago

It takes a certain chutzpah to leave the sort of comments one sees on this issue and the similar one for Backbone. The author hasn't made a secret of his versioning policy. If you have a broken module, you shouldn't have used [EDIT: actually "~" would have been fine] "^" or (my favorite) ">=" as a semver operator when depending on this module on which you depend for free. Anyway, with a decent test suite, surely a modicum of (automated) testing has already identified the pinning that should take place?

abritishguy 12y ago
>The author hasn't made a secret of his versioning policy. No one is going to see that unless they go looking for it though >you shouldn't have used "~", "^" That is how the npm ecosystem works, and in any case the issue arose from dependencies that in turn depended on underscore and thus are not under my direct control. > Anyway, with a decent test suite, surely a modicum of (automated) testing has already identified the pinning that should take place? My particular issue is in a new project I could not install several dependencies as npm downloaded the newest compatible version which was supposedly 1.7.0 - the only way to fix this is to manually create a lock file. >you depend for free. True, and I'm tremendously grateful for all the work that has gone into it and it would be a massive shame if that work was for nothing if a continued disregard for semver forces people to switch to lodash.
- jessaustin 12y ago
  ...dependencies that in turn depended on underscore... Do you imagine that the maintainers of all these dependencies are going to catch any fraction of the hell that jashkenas seems to be catching for this? It's just as much their fault as it is his. Why don't they pin and test?
  - abritishguy 12y ago
    Because that is not the convention in the ecosystem - npm mandates the use of semver - if you follow it this can't happen. If you do what you say and pin it down to an exact version then you would have to release an update every week consisting of just a version bump.

krebby 12y ago

See also https://github.com/jashkenas/underscore/issues/1684 https://github.com/jashkenas/underscore/issues/1684

jashkenas 12y ago

If the asshole responsible for this mess can chime in for a moment ;) I figured that it was worth a bit of a longer explanation (cross-posted from https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e) --- Spurred by this thread, here's is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it. For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0. But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/ http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us. SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that will be affected by the change, the severity of the change (Is it easy to fix my code? Or do I have to rewrite everything?) — into a single number. And unsurprisingly, it's impossible for that single number to contain enough meaningful information. If your package has a minor change in behavior that will "break" for 1% of your users, is that a breaking change? Does that change if the number of affected users is 10%? or 20? How about if instead, it's only a small number of users that will have to change their code, but the change for them will be difficult? — a common event with deprecated unpopular features. Semantic versioning treats all of these scenarios in the same way, even though in a perfect world the consumers of your codebase should be reacting to them in quite different ways. Ultimately, breaking changes are no fun, and we should strive to avoid them when possible. To the extent that SemVer encourages us to avoid changing our public API, it's all for the better. But to the extent that SemVer encourages us to pretend like minor changes in behavior aren't happening all the time; and that it's safe to blindly update packages — it needs to be re-evaluated. Some pieces of software are like icebergs: a small surface area that's visible, and a mountain of private code hidden beneath. For those types of packages, something like SemVer can be helpful. But much of the code on the web, and in repositories like npm, isn't code like that at all — there's a lot of surface area, and minor changes happen frequently. Ultimately, SemVer is a false promise that appeals to many developers — the promise of pain-free, don't-have-to-think-about-it, updates to dependencies. But it simply isn't true. Node doesn't follow SemVer, Rails doesn't do it, Python doesn't do it, Ruby doesn't do it, jQuery doesn't (really) do it, even npm doesn't follow SemVer. There's a distinction that can be drawn here between large packages and tiny ones — but that only goes to show how inappropriate it is for a single number to "define" the compatibility of any large body of code. If you've ever had trouble reconciling your npm dependencies, then you know that it's a false promise. If you've ever depended on a package that attempted to do SemVer, you've missed out on getting updates that probably would have been lovely to get, because of a minor change in behavior that almost certainly wouldn't have affected you. If at this point you're hopping on one foot and saying — wait a minute, Node is 0.x.x — SemVer allows pre-1.0 packages to change anything at any time! You're right! And you're also missing the forest for the trees! Keeping a system that's in heavy production use at pre-1.0 levels for many years is effectively the same thing as not using SemVer in the first place. The responsible way to upgrade isn't to blindly pull in dependencies and assume that all is well just because a version number says so — the responsible way is to set aside five or ten minutes, every once in a while, to go through and update your dependencies, and make any minor changes that need to be made at that time. If an important security fix happens in a version that also contains a breaking change for your app — you still need to adjust your app to get the fix, right? SemVer is woefully inadequate as a scheme that determines compatibility between two pieces of code — even a textual changelog is better. Perhaps a better automated compatibility scheme is possible. One based on matching type signatures against a public API, or comparing the runs of a project's public test suite — imagine a package manager that ran the test suite of the version you're currently using against the code of the version you'd like to upgrade to, and told you exactly what wasn't going to work. But SemVer isn't that. SemVer is pretty close to the most reductive compatibility check you would be able to dream up if you tried. If you pretend like SemVer is going to save you from ever having to deal with a breaking change — you're going to be disappointed. It's better to keep version numbers that reflect the real state and progress of a project, use descriptive changelogs to mark and annotate changes in behavior as they occur, avoid creating breaking changes in the first place whenever possible, and responsibly update your dependencies instead of blindly doing so. Basically, Romantic Versioning, not Semantic Versioning. All that said, okay, okay, fine — Underscore 1.7.0 can be Underscore 2.0.0. Uncle. (typed in haste, excuse any grammar-os, will correct later)

deleted 12y ago

[deleted]

QuantumChaos 12y ago

Can someone outline who the people arguing against Jeremy Ashkenas are? It would make a big difference if they were ordinary users, vs maintainers of other important libraries of pieces of software. While everyone deserves their say, this issue seems somewhat subjective, and a package maintainer shouldn't have to pay undue attention to individual users who don't necessarily represent the whole community.

shadeless 12y ago

I'm a bit surprised no one has mentioned FerVer(Fear-Driven Versioning) yet, it was made in an effort to fix exactly this kind of problem. [1] [1] https://github.com/jonathanong/ferver https://github.com/jonathanong/ferver

Lavinski 12y ago

This link (http://www.jongleberry.com/semver-has-failed-us.html http://www.jongleberry.com/semver-has-failed-us.html) was also posted on HN a while ago. HN: https://news.ycombinator.com/item?id=8154933 https://news.ycombinator.com/item?id=8154933

ricardobeat 12y ago

The blame for this falls squarely on NPM for replacing the default ~ (update patches) with ^ (update minor versions). The only reason for having automatic package updates in the first place is to receive bug and security patches. There is little gain in receiving 'minor' updates if you are not changing your code, and any serious project will end up freezing the dependency tree anyway.

jessaustin 12y ago
Is this ironic? https://github.com/npm/npm/releases/tag/v1.4.3 https://github.com/npm/npm/releases/tag/v1.4.3 [look at the patch number...]

eldude 12y ago

Simple, add an optional human significant "ultra" version (better name suggestions welcome) to indicate a philosophical version upgrade consistent with how major versions have historically been used (as marketing communications). E.g., 1.1.7.0 or 1.7.0 are equivalent. [Cross posted from the other thread: https://news.ycombinator.com/item?id=8244920 https://news.ycombinator.com/item?id=8244920]

deleted 12y ago

[deleted]

wprl 12y ago

It's really not that hard. If you have a lot of breaking changes, you probably shouldn't be at 1.x.x. If you need to deprecate something, add the extra features alongside and remove the deprecated features in the next major release. If you need to add something to code that is >= 1.x.x and you think it will need breaking changes, you should mark the feature as experimental in the documentation until it has stabilized. Semver works great for humans and robots if you put a smidgeon of planning and consideration into the process!