getLastRelease: Find latest version irregardless of dist-tag

[semantic-release]

getLastRelease: Find latest version irregardless of dist-tag

[pvdlg]

If we run getLastRelease with the dist-tag latest, it will say the most recent version is 1.0.0, which isn't true. If analyzeCommits then returns "major", semantic-release will try to release version 2.0.0 and will fail because that version has already been published.

This use case is not currently handled properly by semantic-release. We currently "assume" the user would not do something incoherent such releasing a version on latest that is higher than the last version on next. See semantic-release/semantic-release#563 for the proposed solution.

I believe getLastRelease should always return 2.0.1 in this scenario, regardless of what dist-tag is configured.

The current behavior is intended.
When you are on a branch configured to release on a certain dist-tag you want to make a release on that's dist-tag based on the last version released there.

For example if you configure the master branch to release on latest dist-tag and next branch to release on next dist-tag. And the last version of the code on master correspond to 2.0.0, which is available on latest, and the last version of the code on next correspond to the 3.0.0 which is available only on the next dist-tag.

When you make commits on the next branch you will release on next dist-tag, incrementing the last version there.

If you make a fix commit on master you want to release 2.0.1 on latest. With your proposal that would release a 3.0.1 which would contains the code of 2.0.0 + one fix commit and not the code of 3.0.0.
So when semantic-release runs on master, getLastRelease must return the last release of the corresponding dist-tag which is latest.

[pmowrer]

This use case is not currently handled properly by semantic-release.

I don't think what I describe is a "use-case", but rather how dist-tag works (I could be wrong).

If you make a fix commit on master you want to release 2.0.1 on latest. With your proposal that would release a 3.0.1 which would contains the code of 2.0.0 + one fix commit and not the code of 3.0.0.

I don't think I'm making a "proposal", but rather reporting a bug.
What if 2.0.1 was already released on your next branch? You then wouldn't be able to publish 2.0.1 on master because it's already been published.

[pvdlg]

I don't think what I describe is a "use-case", but rather how dist-tag works (I could be wrong).

The use case I am referring to is to prevent a release when it would create an incoherent situation of 2 release with the same version number having different content. This would be handle by semantic-release/semantic-release#563.

I don't think I'm making a "proposal", but rather reporting a bug.

It's not a bug, as you noted it's by design that npm prevent to publish the same version twice on different dist-tag.

I don't think I'm making a "proposal", but rather reporting a bug.

I was referring to "I believe getLastRelease should always return 2.0.1 in this scenario, regardless of what dist-tag is configured."

What if 2.0.1 was already released on your next branch? You then wouldn't be able to publish 2.0.1 on master because it's already been published.

This is something that is not supported by npm and it will fail. That's the expected behavior. npm dist-tag doesn't enforce anything in your workflow, it's up to you to manage your release workflow to avoid incoherent situation. In that case that means being certain to not release a version that has been released before.
If you have a 2.0.0 on master/latest and a 2.0.1 only on next and you want to push a fix on top of the 2.0.1 then you have to make 2.0.1 available on latest and then push your fix, so 2.0.2 will be published.

[pmowrer]

I think I understand the use-case you're describing. I'd argue that, unless you fully understand (and expect) this workflow, it'd be easy to shoot yourself in the foot with how this works by default. Anyway, thanks for taking the time to explain!

[pvdlg]

it'd be easy to shoot yourself in the foot with how this works by default

Yes. dist-tag are way more complex than what they look like at first. Especially regarding edge cases.
That said, the case explained in this comment where you'd end up releasing a 3.0.1 with the code of 2.0.0 + the fix commit, and without all the 3.0.0 related code committed on next is even wort because you would end up with a release that is incoherent. The case in which we attempt a 2.0.1 release that failed is a bit better because because at least no wrong release has been done.

Hopefully with semantic-release/semantic-release#563 none of this scenario would happen as semantic-release would handle both the release and the change of dist-tag.