Drop support of old Node.js versions

[bsautel]

It sounds like all versions before the 10 LTS are end of life. I think it is no longer necessary to support them.

Removing its support would enable us to simplify the NodeSetupTask and specific cases regarding very old versions (some 4.x or 6.x) for which the zip distribution did not already exist.

We would not have to parse the Node.js version and this would enable versions such as 10.+ to work.

This probably would enable us to fix #95 and #54 more easily.

[deepy]

What I don't like about enabling things such as 10.+ is that it requires us to be able to reach and parse an index page listing all the versions and if someone uses a mirror this isn't necessarily going to work.

Given that these are end of life I think it'd be perfectly reasonable for us to only support them in the download = false scenario

[bsautel]

You are right, there is also another downside which is that your build is not reproducible. And how often do you check whether there is a new version of not? You can't look for newer versions at each nodeSetup run, but if you never do it, you no longer run the latest version... We would probably do the same thing as we do for Yarn now: we install the latest version when the yarnSetup task runs and never update it after.

But as you said, dropping support of those very old versions does not imply we support dynamic Node.js versions.

I am going to remove the code that supports setup of this very old versions.

[deepy]

I guess we could extract the earlier snippet into a documentation entry for those who want to do it and are ok with coding against an index pattern, I think there's luckily some Gradle caching being done so it's not as awful as it could be, but if someone's idea of fun is risking the build breaking between invocations then I'm not going to stop them :-)
There's probably some very legitimate setups like having a nightly job testing against the latest version of node though.

[bsautel]

I'm ok to explain how to do that in the documentation and not support it directly (at least for now).

[deepy]

It has to be better to document how to do this rather than adding API methods for interacting with the IvyRepository right?

[bsautel]

What do you mean by adding API methods? Adding a kind of DSL that would configure a custom repository and that would also set the distBaseUrlto nullso that the default repository is not added?