A "latest" tag

[brock]

Would you consider adding a "latest" git tag whenever there is a version bump?

I didn't see this discussed in a search of issues, so sorry if it has been brought up in the past. I have a "node reinstall" script and recently had to use it, so thought to ask. 💭

[ljharb]

Certainly I could, with git tag -f latest git describe --abbrev=0 --tags`` and then force-pushing the tag, but generally git tags aren't supposed to ever change.

#400 is asking for an nvm update command that would probably work for you as well; ie, install any version that has updating, and then update to the latest - but I'm not sure if, or how quickly, that will land.

I have a strong desire to avoid adding steps to an already-complex release process, and I very strongly do not want to misuse git to achieve anything. I'm open to other ideas to having a pointer to the latest nvm tag.

[brock]

Is the release process explained somewhere, or would you mind sharing some of it with me? I'd offer to look things over and find a solution that's easy for you.

[ljharb]

At the moment, it's TAG=x.y.z make release when I'm ready, I push that commit and its associated tag, and then I manually update travis-ci via PR. Automating that, and adding in automatic changelog generation, are the next things i'd love to add to make release.

[brock]

Thanks for that info. I can see the dilemma in how you link to a tagged version using the raw.ghuc URL.

I dug through the issues last night, but I didn't see talk of pointing to the master branch for the install script. Do you recall why the readme uses a versioned URL instead of master?

https://raw.githubusercontent.com/creationix/nvm/master/install.sh

EDIT: I read #400, #127 and a few others. I keep seeing mention that master shouldn't be used, but I still don't see why? I have this growing suspicion that master is intentionally intended to be something other than the norm: stable and production-ready... I keep telling myself that can't possibly be true, but I fear it is the case. Okay, I'll just come right out and ask it:

what does "master" mean to nvm?

[ljharb]

That's intentional. "master" is what's currently in development - and not yet released. "stable and production-ready" can only be conveyed by an official release with a semver version; master indeed doesn't imply that. It's an exceedingly common workflow in my experience for anything that has a publish/release process - ie, not a large app, but something that is itself a dependency.

[brock]

How would you feel about a branch called "latest"? That's probably the only way around the issue I can think of unless you started to use GitHub's release workflow, but a latest branch would be less overhead. I could work on a pull request this weekend if interested. For now I'm just referencing the master branch in my script, but latest might be a nice permanent URL folks could reference.

[ljharb]

Please reference git tag -f latest git describe --abbrev=0 --tags`` instead of master :-) master isn't safe to be using.

I'm open to suggestions and PRs, but I'm still not convinced this is the right approach.

[brock]

Here is what I'd propose when publishing a new release:

Initially:

• Create a branch called latest (not a tag)
• Update the readme, nvm.sh and install.sh to always point to the latest branch githubusercontent.com/.../latest/...

Then on a new release:

• RELEASE_ID=git describe --abbrev=0 --tags
• Update package.json to use the actual version number (though latest might be okay here)
• Checkout latest branch and reset to origin/latest
• Git merge $RELEASE_ID

[ljharb]

http://latest.nvm.sh/ now redirects, via Github Releases, to the latest version. nvm_get_latest (#599) uses this URL to parse out the version number. I prefer this approach to abusing tags or branches.