Frankly, I feel like this is an indictment of all software development, everywhere. When you need to do this kind of a thing, you are doing it wrong. I do not mean I am doing it any better, I have the same issues e.g. working on Android, but there are probably some fundamental things we could be doing to avoid all these horrible symptoms. Things like NixOS come to mind, where people are actively researching and exper…
Wouldnt the only solution to "see if you code worked with changing apis" to either 1) never change apis even if you were wrong or you have more opportunities or 2) know everything beforehand and implement the api perfect
Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
41–50 of 69 posts
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#42Would you implement binary search? A feature like git-bisect could be usefull to find breaking changes.
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#43Earlier quoted context omitted.
What do you recommend for how we could do it better?
Take a look outside of the node.js micro cosmos.
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#44Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#45Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#46Earlier quoted context omitted.
There are actually 303 versions of node (including iojs, according to the Node Version Manager): $ nvm ls-remote | wc -l 303 Most of those are patch releases. There are 47 minor releases and 6 major releases: $ nvm ls-remote | grep -oE 'v\d+\.\d+' | uniq | wc -l 47 $ nvm ls-remote | grep -oE 'v\d+' | uniq | wc -l 6 Most language implementations probably have similar number of releases.
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 http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...
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?
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#47Earlier quoted context omitted.
There are actually 303 versions of node (including iojs, according to the Node Version Manager): $ nvm ls-remote | wc -l 303 Most of those are patch releases. There are 47 minor releases and 6 major releases: $ nvm ls-remote | grep -oE 'v\d+\.\d+' | uniq | wc -l 47 $ nvm ls-remote | grep -oE 'v\d+' | uniq | wc -l 6 Most language implementations probably have similar number of releases.
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 http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#48Earlier quoted context omitted.
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 http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...
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?
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)
Re: Show HN: Test your JavaScript modules simultaneously in 32 different versions of Node.js
#49Earlier quoted context omitted.
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 http://www.scala-lang.org/download/all.html https://www.python.org/downloads/ etc...
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?
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.
[1] https://github.com/nodejs/node/blob/v5.10.1/CHANGELOG.md