Add upgrade / update command

[kyrylkov]

It would be nice to somehow keep track of Node.js versions installed using version labels (not version numbers) to be able to upgrade them using a single command.

For instance, if I installed several Node.js versions using version labels: nvs add argon, nvs add boron, nvs add latest and nvs add nightly, I would be able to upgrade all version labeled versions using nvs up / nvs upgrade to the latest version of argon, boron, latest and nightly.

[jasongin]

Interesting suggestion. It might be tricky to get all the details right. Some things to think about:

• Would global modules be automatically migrated to the new version?
• Would the previous version be removed?
• What if there are multiple versions installed with the same label? For example multiple builds with the "Boron" LTS tag. Only upgrade the latest?
• Would aliases be updated? (Aliases can refer to labels, specific versions, or partial versions.)
• If a targeted version is set as the default via nvs link, should the link be updated to the new version?
• How do different remote URIs play into this? Maybe it should only operate on the default ("node") remote unless otherwise specified. Note "nightly" is a separate remote, not a version label.

Also, there is another suggestion to add a command to update NVS itself, so the command names should be chosen carefully to avoid confusion.

[kyrylkov]

• Would global modules be automatically migrated to the new version?
• Would the previous version be removed?

I'd need to look at how it currently works

• What if there are multiple versions installed with the same label? For example multiple builds with the "Boron" LTS tag. Only upgrade the latest?

I meant to somehow track whether a specific version was installed by version name or by version label / tag to upgrade only the ones installed by tag. In other words, nvs add 7.8.0 or nvs add 6.10.1 shouldn't be upgraded since I probably need these specific versions. However nvs add latest and nvs add boron, should be upgraded, since I need the latest and greatest from these specific tags.

• Would aliases be updated? (Aliases can refer to labels, specific versions, or partial versions.)

I would think so, based on the previous item.

• If a targeted version is set as the default via nvs link, should the link be updated to the new version?

Only if it was linked to a version label / tag, like nvs link boron (not `nvs link 6.10.1)

• How do different remote URIs play into this? Maybe it should only operate on the default ("node") remote unless otherwise specified. Note "nightly" is a separate remote, not a version label.

Operating on default ("node") remote is fine. Alternatively other remotes except "node" should behave similar to nvs add latest. I.e. using nvs add nightly should allow nightly to be upgraded to the latest version.

Also maybe nvs outdated should be introduced as a precursor to nvs update / nvs upgrade. Basically if I installed nvs add latest and nvs add argon several days ago, nvs outdated would show me if I still have the latest versions for these tags.

[jasongin]

I meant to somehow track whether the version was installed by version name or by version label / tag to upgrade only the ones installed by tag. In other words, nvs add 7.8.0 or nvs add 6.10.1 shouldn't be upgraded since I expressed interest in those specific versions. However nvs add latest, nvs add boron, nvs add nigtly should be upgraded, since I need the latest and greatest from these specific tags.

I don't think I like the idea of having behavior conditional on whether a number or label was used when adding a version.

Any of the following commands will get you the latest LTS Boron release (as of now):

• nvs add lts
• nvs add boron
• nvs add 6
• nvs add 6.10
• nvs add 6.10.1

Even if you use nvs add 6 to refer to it, you still get a build that is known to be labeled as LTS Boron (as seen in the output of nvs ls), and therefore you should be able to refer to it that way interchangeably.

[kyrylkov]

Yes, it makes sense.

However I wanted also to have an option to have certain versions sticky / non-upgradable. This is useful when a new minor release introduces a regression, which might take more than a week to fix in a new release.

This is from my personal experience.

[ljharb]

That is both a rare occurrence and it rarely takes more than hours to fix, depending on the regression. I think when that happens and you're otherwise using the latest release, it's appropriate for you to jump through some hoops to lock it down.

[kyrylkov]

@ljharb Agreed. This whole suggestion came out of desire to keep latest argon, boron, latest and nightly

[jasongin]

Here's a mini spec for how I think this might work, in a way that maintains consistent behavior for how versions are specified and resolved. Does it make sense to you?

nvs upgrade [version]

Upgrade procedure:

1. Identify the remote name and major version number of the version we are upgrading from, specified as the first parameter. It should resolve to some currently-installed version. If no version is specified, the version currently in use is implied, if any.
2. Query the remote to identify the latest available version with the same major version as the specified version.
3. Download and install (nvs add) the newer version, if not already added.
4. Migrate global packages from the old to the new version.
5. If the old version was linked, link the new version instead.
6. Update any aliases pointing specifically to the old version to refer to the new version.
7. Use (nvs use) the new version if the old version was previously in use.
8. Remove the old version.

Examples:

nvs add lts  # Adds 6.10.1
# Some time later 6.10.2 is published
nvs use lts  # Uses 6.10.1 (nvs use does not check for a newer version)
nvs upgrade  # Upgrades from 6.10.1 to 6.10.2

nvs add argon  # Adds 4.8.1
# Some time later 4.9.0 is published
nvs upgrade argon  # Upgrades from 4.8.1 to 4.9.0

nvs add 7.7  # Adds 7.7.4
nvs add 7  # Adds 7.8.0... forgot to use the upgrade command
nvs upgrade 7.7 # Upgrades from 7.7.4 to 7.8.0

nvs add nightly  # Adds the latest build from the "nightly" remote: 8.0.0-nightly20170331...
# One day later
nvs upgrade nightly  # Upgrades from 8.0.0-nightly20170331... to 8.0.0-nightly20170401...

Notes

The upgrade command is constrained to work only within the same major version because I assume that is the behavior people normally want for doing automatic upgrades. It could be possible for the nvs upgrade command to accept a second parameter that is a major version (or specific version?) to upgrade to, but I don't know that would be used much, and might just add confusion.

Should there be an option for the upgrade command that will show you what it would do, without making any actual changes. Or a separate command? That was suggested above as nvs outdated... I'm not sure I like that name but I don't have a better idea at the moment.

[kyrylkov]

LGTM

[jasongin]

An experimental implementation of this feature is in the NVS develop branch, if you want to try it out. I still need to add alias migration, tests, and documentation.

[kyrylkov]

Seems to work perfectly fine

[jasongin]

Done! Merged as f394572, 5b0d80d

https://github.com/jasongin/nvs/blob/master/doc/UPGRADE.md

[kyrylkov]

@jasongin Great job. Congratulations!