maintenance branch releases accidentally blow away "latest" npm dist-tag

[trentm]

Currently on the 4.x branch (now a maintenance branch since 5.0.0 has been released), the make cutarelease target is used to tag and publish a new release. npm publish however will implicitly assign the 'latest' dist tag to this releae. We don't want that for 4.x, because 5.x releases should stay as the "latest".

Proposal: Use npm publish --tag=latest-4. Explicitly using a tag gets npm publish to not implicitly use 'latest'. I'm copying npm's own "latest-$majorver" pattern here:

$ npm info npm dist-tags

{ latest: '5.0.4',
  next: '5.0.4',
  'latest-2': '2.15.12',
  'next-2': '2.15.12',
  'latest-1': '1.4.29',
  lts: '2.15.11',
  'latest-3': '3.10.10',
  'next-3': '3.10.10',
  'latest-4': '4.6.1',
  'next-4': '4.6.1',
  'latest-5': '5.0.4',
  'next-5': '5.0.4',
  'v5.0-next': '5.0.4' }

@retrohacker Sound good?

[retrohacker]

Sorry for the delay on this 😄 got distracted with the weekend.

I'm 👍 on that, but would like --tag=latest-4 to get sourced from package.json using something like awk or grep. CI/CD should be smart enough to publish the correct major version without human input.

[nexdrew]

Looks like this is still an issue? I recently upgraded to v7 and today I see that 4.3.3 is the latest:

$ npm info restify dist-tags
{ latest: '4.3.3', beta: '5.0.0-beta-8.0' }

As a user, this is confusing. I understand that maintenance releases are necessary, but they shouldn't override the latest tag in npm. If someone does npm i restify, they will get version 4.3.3, not knowing that 7.1.0 should actually be the latest.

Are there any plans to address this? What can someone do to help?

[hekike]

@nexdrew thanks for reporting this.
Did someone fix this in the meantime?

For me it returns:

$ npm info restify dist-tags
{ beta: '5.0.0-beta-8.0', latest: '7.1.0' }

[nexdrew]

@hekike I concur, latest now points to 7.1.0. I assume someone with write access for this package on the registry did something like npm dist-tag add restify@7.1.0 latest since my comment two days ago.

Unless the publish process is modified to include a specific --tag <tag> argument (e.g. --tag latest-4 for 4.x maintenance releases), this problem may come up again.

[hekike]

@DonutEspresso fixed the npm tag, but this is still an issue.

[nexdrew]

From what I can tell, unleash does not support a --tag <tag> argument, so if the team is using it for releases, we may need to open an issue there and/or contribute something.

[trentm]

FYI: I'm going to make a change to the earlier 4.x branch.
I'll update the make cutarelease target to use npm publish --tag=latest-4 (getting that "4" major ver from package.json per @retrohacker's request).

It looks like usage of unleash (and CHANGELOG.md et al) started in 5.x.

Given the changes in 5.x and later using unleash, and because there is discussion here about the issue for possible 5.x and 6.x maint releases, I'll change this issue title to not be specific to 4.x.

[nexdrew]

@trentm Awesome, thank you for the update!