Hi Dale,
I think I did write down all the steps involving Maven in the document:
src/site/asciidoc/releasing.adoc
The merge with the other RM doc is that the release-perform will create the
source tar/zip we vote on in “target/checkout/target/***.tar.gz” and the
corresponding zip. The files should follow the exact naming convention used to
deploy it on the staging svn.
In the last release, I manually created the directory structure and checked in
the files. After that I used the existing scripts to deploy the voted-on
release to prod.
But it’s always good for others to try it too … and yes … it will do all the
steps without pushing (it will however create a Maven staging repo). The
staging repo is simply removed by a simple click and with the git repo, a
simple forced git reset should do the trick.
If you run into any problems, I’ll try to help as soon as possible.
Chris
Am 03.01.18, 18:26 schrieb "Dale LaBossiere" <dlab...@apache.org>:
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
