4 ms·

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/commu

yeah -- perhaps there's a lot of negative things to be said about node, but the fact that they've released multiple versions? really? https://clojure.org/community/downloads_older https://clojure.org/community/downloads_older http://www.scala-lang.org/download/all.html http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ https://www.python.org/downloads/ etc...

colanderman 10y ago
I don't think the issue is that they've released multiple versions, it's more that they've had so many backward-incompatible releases. Python and OCaml have had 3 each. Libc has had 6. 32 for something that's been around less than a decade is a bit excessive. Are all these 32 actually backwards-incompatible?
- lucideer 10y ago
  They're not strictly backward incompatible: one should ideally only have to test across the major versions (nodejs is currently on major version 5, though that's not strictly reflective given the fork to iojs, and the change in versioning system on merge back) Testing across all 32 (or 303) versions is still going to be useful for catching bugs and quirks between minor versions (as opposed to deliberate, documented breaking API changes)
  - merb 10y ago
    actually for the sake of correctness, you should also test version 4 which is lts (if you are a library author) (https://github.com/nodejs/LTS https://github.com/nodejs/LTS) I mean v0.10 and v0.12 are also LTS but I doubt that if you have a bigger library that its nearly impossible to support all four
- Nadya 10y ago
  >Are all these 32 actually backwards-incompatible? Node uses semantic versioning [0] and the current release is 5.10.z The breaking changes can be found here [1] By searching for `SEMVER-MAJOR`. Some seem rather unavoidable for progress (updating dependencies...) and some are for things that have been deprecated. I'm not an expert but it looks like there are several security related changes as well? In my eyes a backwards incompatible change that breaks a feature that has been deprecated for years or is insecure is a change worth making. Stability is bad if it means remaining insecure. [0] http://semver.org/ http://semver.org/ [1] https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md
- tlrobinson 10y ago
  If you fix a bug that I'm relying on for the correct behavior of my code then it's not strictly backwards compatible. These versions include a lot of minor and patch releases. Chances are most code will run just fine on most of these versions, but if you can automate testing them all then why not do it?
- AgentME 10y ago
  There have only been 3 major releases with known backwards-incompatible changes. The reason you would want to test your code in so many versions of Node would be to check that you aren't depending on newer features that aren't in older versions that you want to still support. Testing across 32 versions is probably very overkill for most people though.
  - AgentME 10y ago
    (Oh, I meant to say 3 major releases since 0.10, which I arbitrarily picked as what seemed to be the earliest version still in any significant use today.)
deleted 10y ago
[deleted]

colanderman 10y ago

I don't think the issue is that they've released multiple versions, it's more that they've had so many backward-incompatible releases. Python and OCaml have had 3 each. Libc has had 6. 32 for something that's been around less than a decade is a bit excessive. Are all these 32 actually backwards-incompatible?

lucideer 10y ago
They're not strictly backward incompatible: one should ideally only have to test across the major versions (nodejs is currently on major version 5, though that's not strictly reflective given the fork to iojs, and the change in versioning system on merge back) Testing across all 32 (or 303) versions is still going to be useful for catching bugs and quirks between minor versions (as opposed to deliberate, documented breaking API changes)
- merb 10y ago
  actually for the sake of correctness, you should also test version 4 which is lts (if you are a library author) (https://github.com/nodejs/LTS https://github.com/nodejs/LTS) I mean v0.10 and v0.12 are also LTS but I doubt that if you have a bigger library that its nearly impossible to support all four
Nadya 10y ago
>Are all these 32 actually backwards-incompatible? Node uses semantic versioning [0] and the current release is 5.10.z The breaking changes can be found here [1] By searching for `SEMVER-MAJOR`. Some seem rather unavoidable for progress (updating dependencies...) and some are for things that have been deprecated. I'm not an expert but it looks like there are several security related changes as well? In my eyes a backwards incompatible change that breaks a feature that has been deprecated for years or is insecure is a change worth making. Stability is bad if it means remaining insecure. [0] http://semver.org/ http://semver.org/ [1] https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md
tlrobinson 10y ago
If you fix a bug that I'm relying on for the correct behavior of my code then it's not strictly backwards compatible. These versions include a lot of minor and patch releases. Chances are most code will run just fine on most of these versions, but if you can automate testing them all then why not do it?
AgentME 10y ago
There have only been 3 major releases with known backwards-incompatible changes. The reason you would want to test your code in so many versions of Node would be to check that you aren't depending on newer features that aren't in older versions that you want to still support. Testing across 32 versions is probably very overkill for most people though.
- AgentME 10y ago
  (Oh, I meant to say 3 major releases since 0.10, which I arbitrarily picked as what seemed to be the earliest version still in any significant use today.)

deleted 10y ago

[deleted]