Single URL for installing latest version of NVM - by using releases

[NJT145]

At #627 you said it is up to github to give a single url for script. You can put your install script to Releases and do something like this:

curl -L -O "https://github.com/nvm-sh/nvm/releases/latest/download/nvm_sh-$(uname)-$(uname -m).sh"
bash nvm_sh-$(uname)-$(uname -m).sh

At this way, you can also separate different version installation scripts, too.

Or, if you don't want to do that, you can set a script that will get the latest release from github like homebrew did.

I think putting scripts to releases will be much more easier. If you still want to put a single script for all releases, you can still write install.sh instead of nvm_sh-$(uname)-$(uname -m).sh.

[ljharb]

I surely could - but I don't want people doing that. I understand a lot of people want to do that, but that doesn't mean it's a good idea.

If I had asked people what they wanted, they would have said faster horses

attributed to Henry Ford, the inventor of the car.

Annoying or not, you should always explicitly fetch the version number you need (absent semver, where a ^ range would be ideal), and I will always do everything I can to make it harder for people to do the actively harmful thing of blindly grabbing the "latest".

Duplicate of #400.

[NJT145]

You can still block the update on install script. I don't understand why it is a big issue for you? You can still block the update on install.sh and add a nvm update command to update nvm, and everything will be okay.

[ljharb]

Yes, that's what #400 tracks. Such a command would refuse to blindly update across breaking changes, which would be fine.

As much as it's under my control, I will not allow my users to do something that actively harms them, and "just use the latest" is exactly that.

[2colours]

It is ironic, because:

• nvm has a command called install-latest-npm, much riskier in all regards than self upgrading in any way
• the support policy basically says that only the latest version is supported so you are making people - the same people that you don't trust with wanting the right things - to chase after the support constantly, by explicit effort, when it should really just be mutual interest that people are using a supported version
• even on Node's website, the download script has an outdated version of nvm at this very moment: 0.40.0 instead of 0.40.1

At the very least, nvm should provide a command to query the supported versions - which seem to coincide with the sole latest version but that's really just your decision as a maintainer. This is the least to encourage, rather than sabotage, people using supported software.

[ljharb]

@2colours can you link to where on node's website that's the case? I'll try to update it so it's always up to date.

In basically all open source software, only the latest version is supported, unless they have an LTS policy that supports prior release lines, I've just made it explicit here.

Your point about installing the latest npm is valid, but that command largely exists for older node versions where the stock npm simply doesn't work at all.

[2colours]

@2colours can you link to where on node's website that's the case? I'll try to update it so it's always up to date.

https://nodejs.org/en/download/package-manager, select MacOS or Linux and NVM. This is the only place I'm aware of where installation instructions of NVM are mentioned - it's not obscure, at least.

Anyway, I think you are just way too fixated on throwing a somewhat moody obstacle into the way of users to use an up-to-date version of - not even a platform but just a utility script. There is no question that you can always "argue your way out" of the finite number of funny peculiaritites and inconsistencies with this apparent policy - but is that a worthy goal to begin with?

The point is really simple: the users prefer to use supported software, especially with a utility script that can barely break anything. The maintainer should, I suppose, also prefer people using the supported version. And yet no easy upgrade path is available; the people aren't informed about end of support or new versions in any way; they have to keep track of it or query it by themselves, and even if they do that (I reckon they don't), it's not only possible but as we can see, it does happen in actual reality that the most obvious place to download a new version is not even an up-to-date, supported - yes, "latest" - version.

Is this agenda really worth so much? These are all just obvious manual usage issues so far, we haven't even talked about CI/CD where it's almost certain one wouldn't want to pin utility scripts but would always just want to receive a working version and rather pin the parameters of the environment to be built, then deploy the environment and drop the script.

[ljharb]

I would rather explicitly support old versions than allow blindly updating it the latest, not that i think that’s a decision i have to make.

The easiest possible upgrade path is available, one that works on basically all software: just install the new version, which you can get from the readme. You can even watch releases on the repo if you want to be notified when there’s a new one.

[2colours]

I would rather explicitly support old versions than allow blindly updating it the latest, not that i think that’s a decision i have to make.

My point exactly. You don't really make a good case for it - definitely not a good enough case that would explain the resistance to anything that would make getting updates (and staying supported) easier.

The easiest possible upgrade path is available

I can't see how this is easier than any of these:

• a self-upgrade with any sort of configuration
• a reliable and automatable way to receiving "the latest" (any supported, whatever) version
• a way to get information about available updates within the script

you can get from the readme. You can even watch releases on the repo if you want to be notified when there’s a new one.

I can't be the only one who only got this script to begin with because it was recommended on the Node site. This really is just a one-off utility tool, something that could even come preinstalled with Node, not something I would ever want to explicitly track.

Anyway, you are right, one could simply do that. Just like one could simply make a decision about their own upgrade policy even if there is actually an easy way to run the upgrades. If your whole point is that people cannot be trusted with "drugs" like that, why do you suddenly trust them to put a nontrivial amount of attention into a one-off utility tool, rather than the more likely outcome: just missing out on the updates altogether?

Maybe I am the customer who wanted faster horses rather than cars (although I don't think that analogy was a good fit here in the first place) but now that the main recommendation on the Node site is actually fnm and not nvm - which at least does use a fixed url for the version people are supposed to download anyway - I see no point in "fighting harder" for nvm when I heavily disagree with this "agenda over practical considerations" maintainer attitude anyway and rather wouldn't legitimate it by using the tool when there are fine alternatives.

[ljharb]

The recently redesigned node site indeed has the flaw you're pointing out, and I will definitely be fixing it so that it always shows the latest version in the instructions.

Additionally, the default recommendation as far as I'm aware is only fnm if you initially load the page on Windows - on Mac and Linux, it defaults to nvm (the dropdown is sticky, though, as you change OS's, so if whatever was set is available on the OS you change to, it will remain set).

You are of course more than welcome to select your software based on your comfort level with the maintainer's attitude, just as a maintainer of an open source product doesn't ever have to justify anything to anyone - open source comes "as is".