You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Elliotte Rusty Harold (Jira)" <ji...@apache.org> on 2019/12/22 12:15:00 UTC

[jira] [Commented] (MRELEASE-845) Improvements to processing strategy

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

Elliotte Rusty Harold commented on MRELEASE-845:
------------------------------------------------

Makes sense but would this be a breaking change?

> Improvements to processing strategy
> -----------------------------------
>
>                 Key: MRELEASE-845
>                 URL: https://issues.apache.org/jira/browse/MRELEASE-845
>             Project: Maven Release Plugin
>          Issue Type: Improvement
>            Reporter: Sebb
>            Priority: Major
>
> AIUI the present behaviour is as follows (assume trunk is 1.0-SNAPSHOT)
> * update trunk poms <scm> to tags/1.0 and version to 1.0
> * create tags/1.0 from trunk workspace
> * update <scm> to trunk and trunk to 1.1-SNAPSHOT
> This is not ideal for the following reasons:
> * Trunk is temporarily set to a non-SNAPSHOT version. This causes problems for CI servers. Trunk should never be set to a non-SNAPSHOT version, even briefly.
> * trunk is updated to the next snapshot version, even though the release vote may fail. That has two disadvantages: 
> + CI servers may deploy 1.1-SNAPSHOT versions during the release vote. If the release vote fails any subsequent snapshots from trunk will appear to be older until such time as the release vote succeeds or someone deletes the incorrect snapshots.
> + failures require downdating trunk before any fixes can be made. This creates a lot of unnecessary noise on the commit mail list.
> There's another issue: when the tag is created, it is created with the final tag name, e.g. tags/xyz_1.0. If the vote fails, then the tag has to be deleted. However tags should be immutable.
> What I think should happen is as follows:
> release candidate preparation
> =============================
> Trunk is not updated (only checked for SNAPSHOT).
> A new working copy is created from trunk.
> The poms are updated to the non-SNAPSHOT version, and the <scm> entries are updated to the final tag name.
> A new tag is created from the workspace with an RC1 suffix. 
> Note: this is different from the <scm> entries, which don't have the suffix.
> release candidate failure
> =========================
> The trunk pom is updated with the new RC version (RC2)
> Any required fixes are made and a new RC2 tag created as above
> Repeat as needed.
> release candidate success
> =========================
> The release tag is copied to the final tag (i.e. dropping the RCm suffix)
> Trunk is updated to 1.1-SNAPSHOT
> Failed RCn tags can be deleted if required.
> ===
> The advantage of the revised process is that trunk is only updated when necessary; it is never in a transient (or incorrect) state. Also tags are immutable.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)