[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467791#comment-17467791
]
Christopher Tubbs commented on MRELEASE-938:
--------------------------------------------
[~rfscholte] I don't understand how to use the MRELEASE-956 changes, if they
are even documented anywhere. It may be possible to use that feature to
customize the release strategy to satisfy the use case here, but I just don't
know how right now. If you can point me to documentation on how to use it, I
can evaluate it to see if it works for the above use case.
[~michael-o] While the description of the problem is complex, the actual
solutions don't have to be.
The problem I've described is not about version numbers at all, but of git tag
management. So, liberally burning through version numbers doesn't solve
anything. Furthermore, it would be a *really* bad idea to adopt the same naming
convention for tags of unreleased versions as those of released versions. The
naming convention that INFRA recommends (requires?) for releases, which is
{{rel*}}, implies that tags following that naming convention are *releases*.
Unreleased versions burned through in this manner shouldn't occupy the same
space. Deleting them and leaving gaps could also be confusing for users,
because gaps could mean an unreleased burned version number, or a released
version number that somebody forgot to tag.
The problem is complicated and difficult to explain, as is explaining why
proposed alternatives like these are insufficient. But, the solutions don't
have to be that complex. They just have to provide a little more flexibility to
prepare a release without creating a tag in its final after-vote location.
Without some way to easily prepare a release candidate without creating a
release tag, you have to set {{pushChanges}} to false and {{localCheckout}} to
true like in
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/pom.xml#L832-L833
and then you have to manually push your release candidate branches and delete
the local tag that this plugin created, or you have to do all that in a script
outside of this plugin, like in
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/assemble/build.sh
, which makes this plugin substantially less useful when you still need
external scripts to prepare a release candidate instead of just running
{{release:prepare}} and {{release:perform}}.
> Need better support for staging release candidates with git and Nexus
> ---------------------------------------------------------------------
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
> Issue Type: Improvement
> Reporter: Christopher Tubbs
> Priority: Major
> Fix For: waiting-for-feedback
>
>
> Use case:
> An ASF project creates git tags which are GPG-signed named "rel/<version>"
> after a release is voted on. If the release passes, the contents of the
> pom.xml files should refer to this final tag, and not any intermediate
> release candidate tag name.
> To avoid pushing the release prior to building a release candidate and
> publishing it to the staging maven repository, the configuration sets
> {{<pushChanges>false</pushChanges>}} and
> {{<localCheckout>true</localCheckout>}}, and the tag name is created with
> {{<tagNameFormat>rel/@\{project.version\}</tagNameFormat>}}.
> There is still a risk of a release manager accidentally pushing the tag
> created by the maven-release-plugin, which has the final name, but is not GPG
> signed, and should not be pushed, because it cannot (and should not) change
> once it is.
> What might be useful here is an alternate, intermediate name,
> {{@\{project.version\}}} which can be used as the checkout tag for the
> perform step.
> Alternatively, no tag actually has to be created in this case (a GPG-signed
> tag is manually created later). Unless {{suppressCommitBeforeTag}} is set,
> the perform step can check out from {{HEAD~1}}, instead. An option to skip
> tag creation entirely could work under these circumstances.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
