Change parts in the sections:
- Preparing the vote of the PPMC on the release
- Preparing the release without the Release Plugin


Branch: refs/heads/overhauling-release-guide
Commit: 3b31d180b1ec178ccd5a10f55155bd612e9d15df
Parents: eb6c2f9
Author: Oliver B. Fischer <>
Authored: Thu Aug 10 20:57:50 2017 +0200
Committer: Oliver B. Fischer <>
Committed: Thu Aug 10 20:57:50 2017 +0200

 content/release-guide.adoc | 149 +++++++++++++++++++++++++++++++---------
 1 file changed, 117 insertions(+), 32 deletions(-)
diff --git a/content/release-guide.adoc b/content/release-guide.adoc
index 69ac10a..86b8dfa 100644
--- a/content/release-guide.adoc
+++ b/content/release-guide.adoc
@@ -3,8 +3,6 @@
 :sectnums: yes
-# to read before
 // to read before
@@ -121,7 +119,7 @@ as the PPMC of Apache Tamaya have approved the release.
 Before you can present the proposed release to the
-IPMC of the Apache Incubator, the proposd release must be
+IPMC of the Apache Incubator, the proposed release must be
 approved by the PPMC of the Tamaya project.
 Therefore you must run a vote on the proposed release
@@ -133,6 +131,13 @@ repository in Apache's Nexus. This sounds complicated
 but it isn't that complicated if you follow the steps
 of this guide.
+In case the vote candidate does not pass the vote of
+the PPMC or the IPMC you can choose between
+canceling the current attempt for the next release
+or you try to fix the issues which hinders people to
+vote with yes. If you have choosen the second
+way then you have to prepare a new vote candidat.
 Rewritten until here
@@ -147,74 +152,154 @@ Rewritten until here
 === Preparing the release without the Release Plugin
-The release plugin is great, but in some cases it breaks even, when 
release:prepare -DdryRun=true was successful.
-Preparing the release vote without the release plugin is stright forward:
+We tried to use the[Maven Release 
+to increase the level of automatisation of the release process, but
+we were not able to get the Maven Release Plugin working as we
+need it for our release process. Therefore we decided not to use
-* As described checkout a release branch of the current head
-* Then us maven and git commands to prepare the release:
+The first step is to create a separate branch for the release canidate.
+The name should consist of the release version and the number of the
+voting candidate.
+For example if you would like to run a vote for the 1.0 release of
+Tamaya API&Core during its incubation for the second time, the usual
+branch name would be `vote-1.0-incubating-02`.
+Follow the instructions below to create the branch for the vote
+and to build the vote candidate.
+.Creating the vote branch and building the vote candidat
-$ git checkout -b vote-tamaya-[release version]
+$ git checkout -b vote-[release version]-[attempt]                             
          <1> <2>
 $ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=200m"
 $ mvn versions:set versions:commit -DnewVersion=[release version] 
-# build the release locally and sign it with your certs
-$ mvn clean install -DperformRelease=true -Dgpg.keyname=1336D3E6 
+$ mvn clean install -DperformRelease=true -Dgpg.keyname=[key] 
-Dgpg.passphrase=[passphrase] <3> <4>
+<1> The version number of the planed release, e.g. `0.4-incubating`
+<2> The number of the current vote, e.g. `03`
+<3> The id of your GPG key.
+<4> The passphrase of you GPG key.
-* Check if everything is in place and correct, when finished you can tag and 
deploy the release...
+Now you can check the source distribution and the Maven artifacts created
+during the build.
+If everything is correct, deploy them to a staging repository on Apache's
+.Deploying the vote candidate to Apache's Nexus'
-$ mvn deploy -DperformRelease=true -Dgpg.keyname=1336D3E6 
+$ mvn deploy
-* check the created commits including user-name and email
-* login to[^] and go to "Staging Repositories"
-* check the contents of the newly created tamaya staging repository
-* _close_ the repository to let Nexus do its validations
-* On success:
-* push the release-branch to the git repo
+// Check if these commandline parameters are needed
+// -DperformRelease=true -Dgpg.keyname=[key] -Dgpg.passphrase=[passphrase] <1> 
+After deploying the artifacts you have to check the staging repository
+created in Apache's Nexus:
+1. Login to[^] and go to _Staging Repositories_.
+2. Check the Contents of the newly create staging repository for you release.
+3. Close the staging repository to let Nexus do its validations on the deployed
+   artifacts.
+IMPORTANT: Do not release the content of the stating repository right now.
+           Releasing means to publish the artifacts. This will be done
+           after a successful vote of the IPMC.
+If everything is correct until now, commit your local changes, create a tag for
+the voting candidate and push the tag and your commits to the Git
+.Commiting the changes done for the vote candidate
 $ git add -A
 $ git commit -m "Release Prepare: Set release version."
-$ git tag vote01-[release-version]
+$ git tag vote-[release version]-[attempt]
 $ git push --tags
-Finally open the next development version:
+<1> The version number of the planed release, e.g. `0.4-incubating`
+<2> The number of the current vote, e.g. `03`
+Finally open the next development version of the project.
+.Set next development version of the project
-# example: newVersion=0.3-incubating-SNAPSHOT
-$ mvn version:set versions:commit -DnewVersion=[development-version]
+$ mvn version:set versions:commit -DnewVersion=[development version]  <1>
 $ git add -A
 $ git commit -m "Release Prepare: Open new development version."
+<1> Next development version, e.g. `0.83-incubating-SNAPSHOT`
+After setting the new development version you have to add the source
+distribution to the distribution repository at[^].
+IMPORTANT: The source distribution and all required artifacts must be added
+           to the development directory of Apache's distribution server.
+           After the approvement of the release candidate by the PPMC and
+           the IPMC they will be moved to the release directory.
-* Add the distribution artifacts to the dev repositories:
+.Adding all needed artifacts to distribution repository
 $ svn co
-$ mkdir [version]
-$ set RELEASE_HOME='pwd'/[version]
+$ mkdir [release version]/[project]                                          
+$ set RELEASE_HOME=`pwd`/[release version]/[project]
+$ set PROJECT_ROOT=[repository of the project]                               
-$ cp rat.txt $RELEASE_HOME
-# Copy everything from
+$ cp $PROJECT_ROOT/cp distribution/target/*{.tar.gz,.zip,.asc} $RELEASE_HOME 
+$ svn add [version]
+$ svn add [version]/[project]
+<1> We store the artifacts of Tamaya API&Core and Tamaya Extensions always
+    in different subdirectories. So _project_ can be either
+    `apiandcore` or `extensions`.
+<2> `PROJECT_ROOT` is the Git repository of the project which you want to
+    release.
+<3> This command copies both distribution archives to `$RELEASE_HOME`.
+Additionally there must be a SHA-1 and MD5 sigature file for each distribution
+archive and its GPG signature (`.asc`). To generate them you need programs
+like `md5` and `shasum`. The name of these programs might vary from system to 
+.Generating the required SHA-1 and MD5 signatures
+$ for f in $(ls *{.tar.gz,.zip,.asc}); do shasum -a 1 $f > ${f}.sha1; md5 $f > 
${f}.md5; done
+After generating the signature files you can add and commit all files and 
+of the source distribution.
+.Adding and commiting the source distribution
+$ svn add [project]
 $ svn add [version]
-$ svn commit --username <apacheId>
+$ svn commit --username [Apache ID]
-* Check contents on[version]
+All commited files and artifacts should be now available via
 == Start the vote

Reply via email to