[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468612#comment-17468612
]
Christopher Tubbs commented on MRELEASE-938:
--------------------------------------------
[~hboutemy] re: "too Git tag oriented" - I created this issue specifically
because this plugin creates an inconvenient git tag. This issue isn't intended
to be about anything else. So, yes, the focus is on the git tag. To answer your
questions:
* The version in the POM for the release candidate is the final version. We
don't append "-rc1" to it because we don't want that in the final released
artifacts. We don't change any bits between voting and publishing, not even to
modify the version number, as that would change the signatures and checksums
evaluated during the vote.
* The version doesn't change if it is accepted
* The convenience binaries don't matter for this discussion, but they sit in
staging repository at repository.apache.org; any POM information in their
META-INF directory would match the corresponding POM in the source artifacts
being voted on
Here's another attempt at trying to summarize the problem using the relevant
actions taken by this plugin, and an example version {{1.0.0}}:
# {{[release:prepare]}} writes a tag name at
{{<scm><tag>rel/project-1.0.0</tag></scm>}} in the pom.xml,
# {{[release:prepare]}} creates a git tag at {{rel/project-1.0.0}},
# {{[release:perform]}} executes maven-assembly-plugin using the source-release
assembly descriptor defined in the ASF parent POM, which stores the POM from
step 1 in the source release artifact that is currently being staged
The core of the problem is that step 1 and 2 above are reusing the same tag
name for different purposes. The {{<scm><tag>}} recorded in step 1 is
effectively permalink information so you can find the git history that
corresponds to a given release, and could be thought of as a "final tag" for a
released version. The tag currently created in step 2 and checked out in step 3
serves a more transient purpose, and could be thought of as a "release
candidate tag". A release candidate shouldn't create a tag following final tag
naming conventions until after a successful vote, and a final tag shouldn't
document a release candidate name in {{<scm><tag>}}. This entire issue is
trying to keep those two separate with limited configuration options made
available by this plugin.
{code:xml}
<configuration>
<!-- existing config options -->
<tagNameFormat>rel/project-@{project.version}</tagNameFormat><!-- used for
scm.tag "permalink" -->
<pushChanges>true</pushChanges>
<localCheckout>true</localCheckout>
<!-- hypothetical possible new config options -->
<checkoutTagFormat>rc/project-@{project.version}</checkoutTagFormat>
<createFinalTag>false</createFinalTag><!-- write resolved tagNameFormat to
scm.tag, but don't create a final tag -->
<pushTags>false</pushTags><!-- use localCheckout instead of pushing. Set to
true to tag save release candidate tags -->
<deleteCheckoutTag>true</deleteCheckoutTag><!-- delete the local rc tag after
release:perform -->
</configuration>
{code}
> 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)
