[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
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
{{rel/project-1.0.0}} 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 {{}} 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 {{}}. This entire issue is
trying to keep those two separate with limited configuration options made
available by this plugin.
{code:xml}
rel/project-@{project.version}
true
true
rc/project-@{project.version}
false
false
true
{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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468425#comment-17468425
]
Michael Osipov commented on MRELEASE-938:
-
[~hboutemy], as far as I know what they consider an RC is *not* mentioned in
the POM. It is just in the vote. I never understood that and it confused me.
E.g., VOTE on RC1 of 1.1.0, but says 1.1.0 and *not* 1.1.0-rc-1.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468390#comment-17468390
]
Michael Osipov commented on MRELEASE-938:
-
It is, multistage, but both are selfcontained, I'd say. You also must consider,
that the whole process expects the tag to be there to switch and and build
from. Not in the current ractor.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468195#comment-17468195
]
Christopher Tubbs commented on MRELEASE-938:
{{release:prepare}} and {{release:perform}} are already kind of multi-stage. It
would also suffice to just have an option that disables creating the tag. For
the {{release:perform}} step, instead of checking out the tag from the name in
{{}}, the {{release:prepare}} step could just record the git commit
hash that it would have created the tag from, so that {{release:perform}} can
check that out instead.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468190#comment-17468190
]
Michael Osipov commented on MRELEASE-938:
-
Well, you basically need a multistage {{maven-asf-release-plugin}}. I guess
that the general plugin flow will not change.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467849#comment-17467849
]
Michael Osipov commented on MRELEASE-938:
-
[~ctubbsii], ASF releases are solely source zip files, that's it. No Git or
Subversion tags. We vote on the zip file, not the Git tag. [~hboutemy].
Regarding prefixes: If everything has the same prefix then the prefix is
redundant.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467791#comment-17467791
]
Christopher Tubbs commented on MRELEASE-938:
[~rfscholte] I don't understand how to use the MRELEASE-956 changes, if they
are even documented anywhere. It may be possible to use that feature to
customize the release strategy to satisfy the use case here, but I just don't
know how right now. If you can point me to documentation on how to use it, I
can evaluate it to see if it works for the above use case.
[~michael-o] While the description of the problem is complex, the actual
solutions don't have to be.
The problem I've described is not about version numbers at all, but of git tag
management. So, liberally burning through version numbers doesn't solve
anything. Furthermore, it would be a *really* bad idea to adopt the same naming
convention for tags of unreleased versions as those of released versions. The
naming convention that INFRA recommends (requires?) for releases, which is
{{rel*}}, implies that tags following that naming convention are *releases*.
Unreleased versions burned through in this manner shouldn't occupy the same
space. Deleting them and leaving gaps could also be confusing for users,
because gaps could mean an unreleased burned version number, or a released
version number that somebody forgot to tag.
The problem is complicated and difficult to explain, as is explaining why
proposed alternatives like these are insufficient. But, the solutions don't
have to be that complex. They just have to provide a little more flexibility to
prepare a release without creating a tag in its final after-vote location.
Without some way to easily prepare a release candidate without creating a
release tag, you have to set {{pushChanges}} to false and {{localCheckout}} to
true like in
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/pom.xml#L832-L833
and then you have to manually push your release candidate branches and delete
the local tag that this plugin created, or you have to do all that in a script
outside of this plugin, like in
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/assemble/build.sh
, which makes this plugin substantially less useful when you still need
external scripts to prepare a release candidate instead of just running
{{release:prepare}} and {{release:perform}}.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467484#comment-17467484
]
Michael Osipov commented on MRELEASE-938:
-
I personally don't understand why this complexity is required. Consider you are
voting on release 3.0.5, the vote fails for various reasons, drop the staging
repo, cancel the vote, fix the issue and roll 3.0.6. Versions are cheap. Set
the burned version to archived in JIRA and add all tickets from 3.0.5 to 3.0.6
+ new ones, you are done. This is what we hav been doing with Maven ecosystem
releases for years now.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001881#comment-17001881
]
Robert Scholte commented on MRELEASE-938:
-
I don't think it fixed, but at least it should be easier to implement. What's
hard to extract from the text is: do we need new phases ( see
https://maven.apache.org/maven-release/maven-release-manager/ for existing
phases) and if so: which ones and where in the ordered list? Do we need to to
be able to reconfigure existing phases?
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001861#comment-17001861
]
Elliotte Rusty Harold commented on MRELEASE-938:
Chrostopher,
you're right. I totally misread what you were asking for here, so I'm reopening
it. Thanks for the detailed explanation.
Robert, if you think 3.0.0-M1 and MRELEASE-956 do satisfy the request here,
please close this again.
> 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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
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/"
> 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
> {{false}} and
> {{true}}, and the tag name is created with
> {{rel/@\{project.version\}}}.
> 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)
[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus
[
https://issues.apache.org/jira/browse/MRELEASE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001621#comment-17001621
]
Christopher Tubbs commented on MRELEASE-938:
[~elharo] This can *not* be fixed by Nexus behavior changes, because:
1. Nexus should not have access to the project's git repository to alter the
tags if moving from staged to release, and it certainly shouldn't have the GPG
private keys to create signed tags, and
2. Nexus should not be modifying the pom.xml's scm section to update the tag
name in the pom when moving from staged to release, especially since that would
break the user's GPG signatures on those pom artifacts.
To be clear, although staging to Nexus is a driving use case, the relevant
issues have little to nothing to do with Nexus. This is really about the git
tag management limitations performed this plugin that could be improved.
To attempt to explain it more clearly:
* This plugin creates a git tag during {{prepare}} based on the
{{}}.
* This plugin modifies the {{}} element in the POM's {{}} section
according to the tag name format.
* When you are using the plugin to stage release candidates, you do *not* want
it to create a git tag based on the final release when you don't yet know if
the release candidate will be the final release (especially in ASF if the final
release tag name looks like {{rel/project-version}}, because tags starting with
{{rel}} are locked and can't be deleted without help from INFRA).
Your options are to:
1. skip tag creation and manually create a tag after the release candidate is
decided to be released, or
2. create a tag name format that includes a release candidate sequence number,
like {{rel/project-version-rc1}}.
The problem with option 1 is that this plugin doesn't have any such option to
skip tag creation. You do have the option to skip the git push, but that is
inconvenient, because it isn't the default and it also skips pushing the new
commits in the branch that update the versions in the pom.xml files, and in any
case... even if you skipped pushing, you'd still have a local tag that might
unintentionally get pushed later.
The problem with option 2 is that the pom.xml file's {{scm}} section that this
plugin updated will have the wrong tag name if the release candidate is
approved for release (it will have the tag name ending in "-rc1" rather than
the final tag name, making it more difficult for people with a copy of the
release to be able to find the correct corresponding git tag for the release
associated with a given pom.xml. This is particularly problematic for other
tools like maven-site-plugin, which make use of the scm information in the pom
to create links for users on a project's website that goes back to the tag.
This could be fixed by either of the following two solutions:
1. Add an option of this plugin to skip git tag creation, and expect users to
do that manually later. This will cause problems with the {{perform}} goal's
ability to check out the commit (because the tag won't exist), but {{HEAD~1}}
could be used with {{localCheckout}}, so long as {{suppressCommitBeforeTag}} is
not used. This solution would allow the plugin's modification to the scm
section of the pom to work only once the user manually created their own tag of
the same name, but they wouldn't have to worry about any automatically created
tags made by this plugin that would interfere with that.
Or,
2. This plugin could be modified so that the name of the actual git tag branch
could be specified separately from the final tag name that gets put into the
pom's scm section. So, "project-version-rc1", "project-version-rc2", and
"project-version-rc3" git tags could all be created by this plugin, all
containing the same pom with the scm section showing a tag name that is simply
"project-version". Then, a user can simply create a "project-version" tag from
the same commit as whichever "project-version-rcX" tag was approved for final
release (without having to recreate the staged artifacts in Nexus with a
corrected pom.xml).
I know this is a bit obscure of a use case... so if I've explained it poorly, I
apologize. If both proposed options are rejected, for whatever reason, that's
fine. It's just a bit more work to do local git tag management in a build
script outside of maven... I had just hoped that this release plugin could
handle this (seemingly common) use case so we could encapsulate the entire
release process within the configuration for this plugin.
> 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: Christ
