5 ms·

Please note: I can speak only for the Node.js npm/Yarn ecosystem. This article is terribly outdated. Version ranges are great and the only way to manage correc

by yuchi 9y ago

Please note: I can speak only for the Node.js npm/Yarn ecosystem. This article is terribly outdated. Version ranges are great and the only way to manage correctly your dependencies without having tons of duplicates. Also they are a security guarantee, because with them you can get security fixes “automatically”. Yet there have been problems, that’s why both Yarn and npm@5 implement a lock file which gives you all the guarantees of a range-less package management with the power of a range-based dependency tree. If module developers following this (IMHO not lucid) article start bundling specific versions in their npm packages everyone will suffer. It’s as stupid as it get. Please, do your research before calling out on practices.

rdsubhas 9y ago
node+npm5/yarn, ruby+gemfile, rust+cargo (and maybe a few more) are the best examples for the whole workflow around packaging. Semver ranges (dependency 1.0.x) along with version pinning (lock files that represent the currently installed versions) are the best-case scenario. One can avoid the exercise of "bumping versions" every once in a while (just upgrade all packages within supported semver ranges), get the same semver compatibility guarantees, makes sure all other team members are using same versions, and most importantly the CI process is reproduceable and can be sped up with reliable, non-broken dependency caching. The elephant in the room is Java. Despite its maturity, both mvn and gradle have poor support for ranges and pretty much no concept of lock files. Everyone is left to "bumping versions" by hand all the time, and snapshot versions are pretty much hell and lead to irreproduceable builds. Vendoring the whole tree is only an optional add-on to semver ranges. You can't vendor a whole tree and resolve all nested dependencies if everyone is using directly pinned versions! I think the article might have a fundamental misunderstanding between versioning as a library author and as a user. TL;DR - Semver ranges are great when coupled with version pinning and lock files. If not, there are some trade-offs, and as long as people are aware of the trade-offs, its still better than no ranges.
- rowyourboat 9y ago
  Snapshot versions are great. We wish npm would have them. Only use them for packages you are developing yourself, of course, and never use them outside of development.
  - michaelmior 9y ago
    npm does have something close. You can tag versions with a name and a common convention is to use "next" as a tag. What is lacking is that I don't believe tags can be versioned so you can't have a snapshot per version as you can in Java.
  - yuchi 9y ago
    The “right way” to do that is to publish alpha versions of your code. Snapshotting the state of the tree into a mutable release is calling for problems. Semver also defines a (poorly supported) M.m.b-release+tstamp pattern, so you can release immutable snapshots and have a semver range do the rest. Maven-like snapshot are a requirement for an environment with poor support for transient semver-ranged dependencies, which maven is…
- dahauns 9y ago
  regarding java - take a look at: http://nebula-plugins.github.io/ http://nebula-plugins.github.io/ Haven't worked with them myself, but colleagues are singing high praise.
Cakez0r 9y ago
Did you actually read the article? > Some justify "~1.8.0" because it includes important security updates automatically. ... For what it's worth, I too disagree with using strict, static versions. But the author does specifically address this point, so it would be nice to see a rebuttal.
- yuchi 9y ago
  Yes I read it and it calls it a fallacy. Which is not, it’s a trade off. We could argue about how many developers actually know the implications (which would be a great survey to do), but I believe having this trade off by default has been the right choice for npm/Yarn. Also we need to distinct devs from lead devs, who are the owners of such responsabilities in teams.
- teh_klev 9y ago
  > Did you actually read the article? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html "Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
marichards 9y ago
Getting security fixes automatically is not a good thing. Too many open source projects fail to ensure non-breaking changes or long term support of multiple release versions. So either you rely on greatest(>) that has no guarantees to not break and not just patches (~), you try patches and a new release is effectively end of support or you rely on greatest, fail to do a regular audit and realise the dependency is no longer in active development and will receive any updates (which upon typical discovery would require a change of dependency used). Security isn't just about vulnerability, and I don't like to ask it (because it isn't universal), but is not a risk of system failure often worse than a risk of system vulnerability? It depends somewhat on how critical the system is and defaulting to explicit versions instead of latest is probably a better practice in my opinion. I've done development using NodeJs and on the JVM and found I had far fewer problems with Java dependency management.
- senko 9y ago
  > Too many open source projects fail to ensure non-breaking changes or long term support of multiple release versions. Relying on those projects is not a good thing.
  - digi_owl 9y ago
    When such big names as Gnome can't pull it off, then what projects can one rely on?
    - zer0tonin 9y ago
      For example React doesn't ever introduce breaking change by surprise.
      - lucisferre 9y ago
        I think that should be qualified with "intentionally". Angular is supposed to be following semver but often has "regressions" in point releases which they fix in a following point release. Usually fairly quickly but it is still not guaranteed.
paulddraper 9y ago
Author here. npm5 was released months after this was written. (A breath of fresh after the npm3 had -- look it up -- intentionally non-determinstic versioning based on install history.) If you read the whole article, I conclude with recommending lockfiles and npm shrinkwrap, the traditional JS lockfile solution. Yarn is the new kid and awesome and deserves mention too. Lockfiles are an appropriate choice for JS because of unique dependency loading. For Java and many other ecosystems, fixed versions are appropriate because they automatically deduplicate. There are pros and cons. The absolute most important thing is to achieve determinism. Programming is hard enough as it is.
- yuchi 9y ago
  Hi Paul, thank you for your response here, could you please update the article with some references to the new options available? Would be great if included info for all platforms, not only npm/yarn :)

by yuchi 9y ago

rdsubhas 9y ago

node+npm5/yarn, ruby+gemfile, rust+cargo (and maybe a few more) are the best examples for the whole workflow around packaging. Semver ranges (dependency 1.0.x) along with version pinning (lock files that represent the currently installed versions) are the best-case scenario. One can avoid the exercise of "bumping versions" every once in a while (just upgrade all packages within supported semver ranges), get the same semver compatibility guarantees, makes sure all other team members are using same versions, and most importantly the CI process is reproduceable and can be sped up with reliable, non-broken dependency caching. The elephant in the room is Java. Despite its maturity, both mvn and gradle have poor support for ranges and pretty much no concept of lock files. Everyone is left to "bumping versions" by hand all the time, and snapshot versions are pretty much hell and lead to irreproduceable builds. Vendoring the whole tree is only an optional add-on to semver ranges. You can't vendor a whole tree and resolve all nested dependencies if everyone is using directly pinned versions! I think the article might have a fundamental misunderstanding between versioning as a library author and as a user. TL;DR - Semver ranges are great when coupled with version pinning and lock files. If not, there are some trade-offs, and as long as people are aware of the trade-offs, its still better than no ranges.

rowyourboat 9y ago
Snapshot versions are great. We wish npm would have them. Only use them for packages you are developing yourself, of course, and never use them outside of development.
- michaelmior 9y ago
  npm does have something close. You can tag versions with a name and a common convention is to use "next" as a tag. What is lacking is that I don't believe tags can be versioned so you can't have a snapshot per version as you can in Java.
- yuchi 9y ago
  The “right way” to do that is to publish alpha versions of your code. Snapshotting the state of the tree into a mutable release is calling for problems. Semver also defines a (poorly supported) M.m.b-release+tstamp pattern, so you can release immutable snapshots and have a semver range do the rest. Maven-like snapshot are a requirement for an environment with poor support for transient semver-ranged dependencies, which maven is…
dahauns 9y ago
regarding java - take a look at: http://nebula-plugins.github.io/ http://nebula-plugins.github.io/ Haven't worked with them myself, but colleagues are singing high praise.

Cakez0r 9y ago

Did you actually read the article? > Some justify "~1.8.0" because it includes important security updates automatically. ... For what it's worth, I too disagree with using strict, static versions. But the author does specifically address this point, so it would be nice to see a rebuttal.

yuchi 9y ago
Yes I read it and it calls it a fallacy. Which is not, it’s a trade off. We could argue about how many developers actually know the implications (which would be a great survey to do), but I believe having this trade off by default has been the right choice for npm/Yarn. Also we need to distinct devs from lead devs, who are the owners of such responsabilities in teams.
teh_klev 9y ago
> Did you actually read the article? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html "Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

marichards 9y ago

Getting security fixes automatically is not a good thing. Too many open source projects fail to ensure non-breaking changes or long term support of multiple release versions. So either you rely on greatest(>) that has no guarantees to not break and not just patches (~), you try patches and a new release is effectively end of support or you rely on greatest, fail to do a regular audit and realise the dependency is no longer in active development and will receive any updates (which upon typical discovery would require a change of dependency used). Security isn't just about vulnerability, and I don't like to ask it (because it isn't universal), but is not a risk of system failure often worse than a risk of system vulnerability? It depends somewhat on how critical the system is and defaulting to explicit versions instead of latest is probably a better practice in my opinion. I've done development using NodeJs and on the JVM and found I had far fewer problems with Java dependency management.

senko 9y ago
> Too many open source projects fail to ensure non-breaking changes or long term support of multiple release versions. Relying on those projects is not a good thing.
- digi_owl 9y ago
  When such big names as Gnome can't pull it off, then what projects can one rely on?
  - zer0tonin 9y ago
    For example React doesn't ever introduce breaking change by surprise.
    - lucisferre 9y ago
      I think that should be qualified with "intentionally". Angular is supposed to be following semver but often has "regressions" in point releases which they fix in a following point release. Usually fairly quickly but it is still not guaranteed.

paulddraper 9y ago

Author here. npm5 was released months after this was written. (A breath of fresh after the npm3 had -- look it up -- intentionally non-determinstic versioning based on install history.) If you read the whole article, I conclude with recommending lockfiles and npm shrinkwrap, the traditional JS lockfile solution. Yarn is the new kid and awesome and deserves mention too. Lockfiles are an appropriate choice for JS because of unique dependency loading. For Java and many other ecosystems, fixed versions are appropriate because they automatically deduplicate. There are pros and cons. The absolute most important thing is to achieve determinism. Programming is hard enough as it is.

yuchi 9y ago
Hi Paul, thank you for your response here, could you please update the article with some references to the new options available? Would be great if included info for all platforms, not only npm/yarn :)