[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468416#comment-17468416
]
Herve Boutemy commented on MRELEASE-938:
----------------------------------------
I could not read the whole thread: too long and too Git tag oriented only
but from a high level perspective, what I'm asking is:
- what is the pom.xml version of a release candidate when it is still RC (then
may be later accepted or rejected)?
- what does it become once accepted?
- and in that time, what is the binary jars content? and where are they
available?
(FYI: jars contain META-INF/gid/aid/pom.properties and pom.xml)
perhaps having a concrete example with a timeline would avoid too theoretical
long discussions: T1: create RC1+start vote => T1+3d: vote reject, T2: create
RC2+start vote, ... (eventually T1.1 if nesting helps)
> 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)
