[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468178#comment-17468178
]
Christopher Tubbs commented on MRELEASE-938:
--------------------------------------------
[~michael-o], Yes, I'm aware that releases are source artifacts. I don't
believe I misrepresented that. Some projects use this plugin to stage a release
candidate, because the Apache parent POM is conveniently configured with a
release profile that uses the maven-assembly-plugin, configured with the
apache-source-release-assembly-descriptor, to produce those source artifacts.
This is very convenient, because with a simple execution of the
maven-release-plugin, one can create the release candidate source artifacts
alongside a staged Nexus repository with convenience binaries for evaluation
and testing of release candidates to inform voting PMC members.
This issue isn't about the release artifacts. It's about making it easier to
use this plugin in a workflow where it is used to prepare "ASF release"
candidates. Although the git tag is not the official source release, many
projects have a desire to create a tag in SCM that is sync'd with the official
source release in some way (either has identical contents, or was used to
prepare the source release, or similar). This plugin creates such a tag
already, but it doesn't play nicely with the "ASF release" candidate workflow,
because it creates a destination tag prematurely... before the candidate has
been voted on and approved. In git, once a tag is used, it shouldn't be
updated. So, the same tag shouldn't be re-used. Release candidates should also
not follow the INFRA-provided {{rel*}} protected branch/tag naming convention,
which implies it matches up to a release, for provenance tracking. So, the goal
here is to have an option to continue using all the power of this plugin, but
more easily avoid tag creation until after a vote passes.
> 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)
