[MRELEASE-845] Improvements to processing strategy

**[Sebb](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sebb@apache.org)** opened **[MRELEASE-845](https://issues.apache.org/jira/browse/MRELEASE-845?redirect=false)** and commented

AIUI the present behaviour is as follows (assume trunk is 1.0-SNAPSHOT)
* update trunk poms \ to tags/1.0 and version to 1.0
* create tags/1.0 from trunk workspace
* update \ 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 \ 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 \ 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.

---

**Issue Links:**
- [MRELEASE-721](https://issues.apache.org/jira/browse/MRELEASE-721) Release plugin should not operate on current SVN trunk/branch to create the tag

Start by tracing the release plugin's current processing strategy and review the linked MRELEASE-721 issue for related context. Compare the implementation with the proposed release-candidate workflow, including RC tag creation, retries after failed votes, and final tag promotion. Done means trunk avoids transient versions and release tags remain immutable.

Written by the indexing model from the issue text.