training-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [incubator-training] branch releases/tools/1.0 updated: - Finished the first part of the release documentation fot the build tools.
Date Wed, 09 Sep 2020 11:02:18 GMT
This is an automated email from the ASF dual-hosted git repository.

cdutz pushed a commit to branch releases/tools/1.0
in repository

The following commit(s) were added to refs/heads/releases/tools/1.0 by this push:
     new ab29785  - Finished the first part of the release documentation fot the build tools.
ab29785 is described below

commit ab2978579a356d7604284298731a277b0abaecc8
Author: Christofer Dutz <>
AuthorDate: Wed Sep 9 13:02:05 2020 +0200

    - Finished the first part of the release documentation fot the build tools.
 .../site/asciidoc/developers/releasing-tools.adoc  | 135 +++++++++++++++++++--
 1 file changed, 124 insertions(+), 11 deletions(-)

diff --git a/site/src/site/asciidoc/developers/releasing-tools.adoc b/site/src/site/asciidoc/developers/releasing-tools.adoc
index 7793c29..c057618 100644
--- a/site/src/site/asciidoc/developers/releasing-tools.adoc
+++ b/site/src/site/asciidoc/developers/releasing-tools.adoc
@@ -31,22 +31,135 @@ This makes releasing this a little trickier, but in the end it's a lot
simpler f
 === Creating a release branch
-Normally we would use the maven release plugin to create these, however this would create
3 independent release branchees, which is sort of silly.
-So we'll create it manually.
+First we need to create a release branch.
-   git checkout -b releases/tools/1.0.0
+Do this the following way:
-So as soon as that's done, we should go back to the `develop` branch and update the poms
to new versions.
+  mvn release:branch -DbranchName=releases/tools/1.0
-As in this example we're releasing version `1.0.0`, we will edit them to `1.1.0-SNAPSHOT`.
+NOTE: We're not using the full version here, as this branch should also contain the bugfix
releases and the tags will have the name using the full version. If we used that for the branch
itself we would get name collisions during the release.
-Currently, the following files need updating:
+After this command is done, we will still be on the `develop` branch.
+In order to actually start the release, we need to switch to the release branch which was
previously created.
-- tools/content-parent-resources/pom.xml (Line 35)
-- tools/content-parent-pom/pom.xml (Line 35, Line 70)
-- tools/content-archetype/pom.xml (Line 35)
-- tools/content-archetype/src/main/resources/archetype-resources/pom.xml (Line 25)
+  git checkout releases/tools/1.0
-=== Releasing `content-parent-resources`
+=== Doing the release
+The release itself is done via the `maven-release-plugin`.
+  mvn release:prepare
+The plugin will ask some questions.
+- For the new-release version, just hit `[Enter]` and use the default.
+- For the release tag use: releases/tools/1.0.0 (Or the version used in the question before)
+- For the next development version, again just hit `[Enter]` and use the default.
+The plugin will now:
+- Check if there are any uncommitted files in the release and abort if it finds any.
+- Then it will update the versions of all artifacts in the reactor to the release version.
+- Then check if now any SNAPSHOT version is used and ask to resolve them to release versions
if it finds any (If it finds any, this should be addressed as it should not happen)
+- Then it does a build including tests in order to see if it builds with the new version.
+- If this build is ok, it commits the changed poms with the new versions.
+- Then it tags this version
+- Then it changes the versions to the next version
+- Then it commits these changes too
+- Then it pushes the changes
+The next step now uses the release tag created in the previous step and builds the release
+  mvn release:perform
+This now will:
+- Checkout the tag into the "target/checkout" directory
+- Run a `mvn deploy` build in this clean checkout with enabled `apache-release` profile
+- In this build - due to the `apache-release` profile - will also build `source` jars, `javadoc`
jars, create a source distribution
+- Create md5 hashes for all artifacts
+- Sign all artifacts with your GPG Keys
+- Deploy everything to the `Apache Nexus` Staging repository
+Last thing you need to do after a successful execution of the release:perform step, is:
+- To log in to Apache's Nexus at: (using your apache
+- Select `Staging Repositories` in the `Build Promotion` menu on the left-hand side (If you
can't see it, you've probably not logged in)
+- Use the search box of the `Staging Repositories` tab and search for "training" (It will
probably have only one)
+- Select the entry.
+- Click on the `Close` button.
+- Enter a meaningful message and click `Confirm`
+- Hit the `Refresh` button in the tab untill the column `Status` changes from `open` to `closed`
+- Copy the `URL` displayed in the details tab for the selected staging repo (In my case:
+We're now done with the preparation of the RC from a Maven perspective.
+Next we need to stage the source bundle we will be voting on.
+=== Staging the Release Candidate
+What we've staged in Nexus is the `convenience binaries` part of the release, the official
release will be the source bundle located in SVN.
+These will be located under:
+In our case the tools will be located in a sub-directory `tools`, so the final path to the
`RC1` of version `1.0.0` will be:
+I usually prepare a local directory containing all parts and then just import them into SVN
in one go.
+The local structure for this is then:
+  /tools/1.0.0/rc1/
+  /tools/1.0.0/rc1/
+  /tools/1.0.0/rc1/
+NOTE: Be sure to not take the files form the `target` directory directly, but that you use
the `target/checkout/tools/target` versions instead!
+Then I just import the 1.0.0 directory using the following command
+  svn import tools/1.0.0
-m"Staged RC1 of version 1.0.0 Apache Training tools"
+If this is the first time you are releasing something for the Apache Training (incubating)
project, be sure to add your PGP key to the `KEYS` file at:
+=== Sending out the VOTE email
+Next step is to actually start the vote by sending out the VOTE email.
+Here a template for that:
+E-Mail Topic:
+[VOTE] Apache Training (Incubating) Tools {release-version} RC{rc-number}
+Apache Training (Incubating) Tools {release-version} RC{rc-number} has been staged under
+and it’s time to vote on accepting it for release.
+All Maven artifacts are available under [1]. Voting will be open for 72hr.
+A minimum of 3 binding +1 votes and more binding +1 than binding -1
+are required to pass.
+Release tag: releases/tools/{release-version}
+Hash for the release tag: {replacethiswiththerealgitcommittag}
+Per [3] "Before voting +1 PMC members are required to download
+the signed source code package, compile it as provided, and test
+the resulting executable on their own platform, along with also
+verifying that the package meets the requirements of the ASF policy
+on releases."
+You can achieve the above by following [4].
+[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items in [4])
+[ ]  -1 reject (explanation required)
\ No newline at end of file

View raw message