[ 
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001674#comment-17001674
 ] 

Robert Scholte commented on MRELEASE-938:
-----------------------------------------

We've just released 3.0.0-M1, which contains MRELEASE-956 , which is a way to 
define your own steps of the prepare and perform goals. I had a plan to 
introduce a finalize/complete/... goal which also makes sense in the way ASF 
votes are done. There's a 72h voting period, after then releases can be 
finished. 
I have found somebody  who's already starting with his own strategy to confirm 
the concept works as designed.

> 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
>
> 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.3.4#803005)

Reply via email to