[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468416#comment-17468416
]
Herve Boutemy edited comment on MRELEASE-938 at 1/4/22, 8:02 AM:
-----------------------------------------------------------------
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)
and precise what happens on local disk pom.xml, what happens on source control
(Git if you wish), what happens on remote Nexus repository, ...
was (Author: hboutemy):
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)
