support my-repo@[version] versions

[wyardley]

From what I can see at, e.g., https://docs.sentry.io/product/cli/releases/, Sentry seems to intend for you to use reponame@version (where version is either a commit hash or semver`) vs.

repoPrefix allows generating reponame-1.2.3, but not reponame@1.2.3.

Would you accept a PR to support a different parameter to support this, or do you know of another workaround to tweak the way the plugin receives ctx.nextRelease.version?

[csprocket777]

Why wasn't this merged into master? Sentry wants Semver formats when reporting in releases. Why force the -?

[csprocket777]

I've gone one step further and included a generate-notes step for the plugin that will log the next sentryReleaseVersion in both dry-run and real modes for the purposes of transparency.

Here's the code: (warning, it doesn't have tests and was a quick tool for my purposes. sharing here in case it helps anyone else)

const AggregateError = require('aggregate-error')
const SemanticReleaseError = require('@semantic-release/error')
const getError = require('./get-error')


/**
 * @typedef {import('./types').Context} Context
 * @typedef {import('./types').Config} Config
 */
/**
 * @param {Config} pluginConfig -.
 * @param {Context} ctx -.
 * @returns {Promise<*>} -.
 * @example
 * generate-notes(pluginConfig, ctx)
 */
module.exports = async (pluginConfig, ctx) => {
  try {
    const sentryReleaseVersion = pluginConfig.releasePrefix
      ? `${pluginConfig.releasePrefix}@${ctx.nextRelease.version}`
      : ctx.nextRelease.version
    ctx.logger.log(`Next version tag to be sent to Sentry: ${sentryReleaseVersion}`)
  } catch (err) {
    if (err instanceof AggregateError || err instanceof SemanticReleaseError) {
      throw err
    } else {
      throw getError('ESENTRYDEPLOY', ctx)
    }
  }
}

For anyone else running into this, instead of forking this repo for the functionality described above, you could also patch it through yarn.

Here is my resulting yarn patch file:
@eclass-semantic-release-sentry-releases-npm-3.1.0-87ddca8c75.patch

You would implement it in your package.json file as a resolution:

  "resolutions": {
    "@eclass/semantic-release-sentry-releases@^3.1.0": "patch:@eclass/semantic-release-sentry-releases@npm%3A3.1.0#./.yarn/patches/@eclass-semantic-release-sentry-releases-npm-3.1.0-87ddca8c75.patch",
    "@eclass/semantic-release-sentry-releases@^3.0.0": "patch:@eclass/semantic-release-sentry-releases@npm%3A3.1.0#./.yarn/patches/@eclass-semantic-release-sentry-releases-npm-3.1.0-87ddca8c75.patch"
  },