SebbASF created MRELEASE-845:
--------------------------------

             Summary: Improvements to processing strategy
                 Key: MRELEASE-845
                 URL: https://jira.codehaus.org/browse/MRELEASE-845
             Project: Maven Release Plugin
          Issue Type: Improvement
            Reporter: SebbASF


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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to