Hi Chris, At a high level, we need to ensure someone can reproduce what you just went through for 1.2.0.
It feels like I should try going through the process for a, fictitious at the moment, 1.3.0 release. i.e., going all the way up to staging the release in dist.apache.org and in Nexus (“Closing the staging repository”), then cleaning that all up like it never happened (“Actions if the vote failed”, plus removing the release/1.3 branch). Does that make sense? As long as I don’t “git push” the created branch and pom-version-change commits, is cleanup as easy as just destroying my repo-clone? Looking at src/site/asciidoc/releasing.adoc, it looks pretty complete, but... In the vote-passed case, where’s the step / cmds to merge the release to master? In the vote-failed case, presumably the “fixes” are make on the release branch, and the eventual “Prepare” redo with the same args does what’s needed. But where’s the step / (cherrypick?) cmds to get the fixes to the develop branch? (imagine there are numerous commits for the fixes) I’m also unclear on the flow for a bug fix release like 1.2.1. Just make the changes on the release/1.2 branch and BEGIN the process with “mvn release:prepare … -tag edgent-1.2.1 -DdevelopmentVersion=1.2.2-SNAPSHOT -DreleaseVersion=1.2.1”? And again steps / (cherrypick?) cmds to get the 1.2.1 fixes to the develop branch. Once I can get through this I’ll update the RM-guide. At least initially I’ll leave releasing.adoc as is (covering what it covers) and just update the RM-guide accordingly and link to it. I don’t want to duplicate info and I don’t want to merge it into a single doc — unless you agree that migrating releasing.adoc content to the wiki (and removing releasing.adoc) is OK :-) — Dale
