Expose getLastRelease step to plugins

[jpoehnelt]

New feature motivation

The major.minor version of my package is triggered from an external source. I want to use this as the last release and allow semantic-release to only be concerned with the patch and prerelease versions. Related: semantic-release/commit-analyzer#180

Additionally, migrating repositories or trying to start at a specific version is not well supported by semantic-release. This functionality would allow more flexibility.

New feature description

Allow plugins to determine the last release and set context.lastRelease.

New feature implementation

await plugins.getLastRelease(context);

if (!context.lastRelease) {
   context.lastRelease = getLastRelease(context);
}

[travi]

the use case that you describe seems to avoid versioning packages semantically, which is a core goal of semantic-release. please keep in mind that semantic-release is not simply a generic tool for automated package publishing but a tool to encourage proper semantic-versioning and to make doing so properly as simple as possible. forcing a package's version to rely on the version of some external source means that the version does not semantically communicate the impact of the changes in that package.

while we recognize that the flexibility of the pieces of this toolset make it almost a fit for some use cases outside of the intended/supported ones, we have to be careful to keep that configurability in check to reduce our maintenance burden for supporting unsupported use cases.

we appreciate the clear issues that you opened and the work you put into your PR, but we dont think this use case is a fit for semantic-release. in the future, we suggest opening an issue with the primary goal first in order to gain alignment before putting in too much effort into an implementation.

[jpoehnelt]

the use case that you describe seems to avoid versioning packages semantically

Semver, https://semver.org/, does not disallow additional bumps in version. It only states:

MUST be incremented if any backwards incompatible changes

[jpoehnelt]

This also gives more flexibility in migration and allow developers customization to bypass bugs or avoid having to recreate some specific git state. The calculation of the last release is unnecessarily strict in my opinion. The getLastRelease leads to many issues:

• Integration issue with existing repo that's following semver already #1685
• Latest git tag/release is not getting used when creating a new release #1535
• Version calculation is creating duplicate version #1531
• Missing tags on repo cloned by GitLab CI #1410
• many more

[jpoehnelt]

This would also allow support for gitflow, #1231 (comment).

[gr2m]

we really do not want to support gitflow. It's on us to support both the code and all the additional use cases this change would permit. And as an independent Open Source project we we are not willing to do that. Sorry to disappoint, but we have to say no to keep the project maintainable, it's hard enough as is.

I'm not saying that we won't change our mind in future, but not at this point

[nolde]

Leaving this here for anyone in a similar situation:

The plugin https://github.com/saitho/semantic-release-backmerge solves the issue of gitflow compatibility by merging master back into develop (or rebasing develop over master, your choice). Works quite well.