Need documentation or mechanism for re-building a release tag

[bchristensen-itron]

First off, this plugin is exactly what I was looking for so thank you for putting this together!

One use case I struggled with was how to reproduce a build from one of the release tags. I understand the reasoning behind not committing the de-snapshotted version of the POMs when a release is run, but this does make reproducing that artifact tricky. If I check out a tagged version it contains the SNAPSHOT versions of all modules and I need to de-snapshot them by re-running the releaser plugin again. But this turns out to be kind of tricky.

Let's say I have a project like:

• library-parent
  • module-api
  • module-internal (depends on module-api)

If I check out an older release tag like:

git checkout tags/module-api-1.0.3

and then run releaser:next to see what the plugin will do:

mvn releaser:next

[INFO] --- multi-module-maven-release-plugin:3.6.1:next (default-cli) @ library-parent ---
[INFO] Will use version 1.0.4 for library-parent as it has not been changed since that release.
[INFO] Will use version 1.0.3 for module-api as it has not been changed since that release.
[INFO] Will use version 1.0.3 for module-internal as it has not been changed since that release.
[WARNING] No changes have been detected in any modules so will not perform release

The plugin has decided that there are no changes since the last tag, which makes sense since we checked out the release
tag. But that also means it won't de-snapshot and run a build for us.

I then tried to force the release:

mvn releaser:next -DforceRelease=module-api

[INFO] --- multi-module-maven-release-plugin:3.6.1:next (default-cli) @ library-parent ---
[INFO] Will use version 1.0.4 for library-parent as it has not been changed since that release.
[INFO] Releasing module-api 1.0.4 as we was asked to forced release.
[INFO] Releasing module-internal 1.0.6 as module-api has changed.

But this doesn't seem correct either. Notice that it will release module-api but as 1.0.4 when we just
checked out 1.0.3. It also seems to pick up later tags for other modules, notice that it's choosing
module-internal-1.0.6 even though the version as of this tag was module-internal-1.0.3

The workaround I found was to trick the plugin into thinking it's never released this commit before. To do that, you need to delete the release tags from this commit and all tags following this commit:

# Checkout the release tag
git checkout tags/module-api-1.0.3

# Delete ALL tags containing this same commit.  This deletes the module-api-1.0.3 tag, other module tags on the 
# same commit, and all future tags in the repo
git tag -d $(git tag --contains=$(git rev-list -n 1 tags/module-api-1.0.3))

# See what the plugin wants to do but don't push or pull tags since we don't want to break the origin repository or 
# restore the tags we just deleted
mvn releaser:next -DpushTags=false -Dpull=false

[INFO] --- multi-module-maven-release-plugin:3.6.1:next (default-cli) @ library-parent ---
[INFO] Will use version 1.0.4 for library-parent as it has changed since the last release.
[INFO] Releasing module-api 1.0.3 as library-parent has changed.
[INFO] Releasing module-internal 1.0.3 as library-parent has changed.

This seems to do what I want, but it feels a bit dangerous since I had to delete all of the future release tags in the local repository and I could accidentally mess up the origin repository state. Is there a better way to re-build an existing release tag that I'm missing?

If not, perhaps a new goal could be added that automates the process, something like releaser:rebuild-tag -DversionTag=module-api-1.0.3.

[danielflower]

Hi, thanks for the comments. This use case hasn't really been looked at (there are no tests for it anyway). It's not very clear what the "correct" approach would be anyway - reuse the tags generated at the time without creating new ones? But there are edge cases to that I think.

I don't think there is going to be a way to rebuild with the same version numbers unless you are willing to delete the tags. If it doesn't happen often, you could always fork the repo and delete all the tags created during the original release (and subsequent tags) and then just rebuild, as you suggested. But it feels safer being in a fork.

If you are willing to introduce a commit, you could use the versions plugin to update the versions. e.g. if you want to rebuild 1.0.3 (which would have been from a 1.0-SNAPSHOT version in the pom) then update the version to 1.0.3-SNAPSHOT and commit this in a new branch. This would then generate a version like 1.0.3.0. Depending on what you want this might be okay - in this case there is a bit of an audit history which would show that the artifact was the same as the original 1.0.3 artifact but that it's actually a rebuild of that (which may be a slightly different artifact due to a different build environment).