This document summarizes the steps of release process for Qpid Java Components

Pre-Requirements

The release process is based on Apache Release PolicyRelease Signing and Publishing of Maven Documents

PGP

Release artifacts needs to be signed. GNU Privacy Guard from OpenPGP is used to sign on Apache. Please, refer Release Signing about PGP public key cryptography. The document provides basic information about release signing and contains links to various resources about PGP public key cryptography and how to use GNU Privacy Guard to generate and sign the PGP keys. Install GNU Privacy Guard, generate keys following steps provided here and upload public keys to keyservers . After publishing keys, login into https://id.apache.org and enter PGP key fingerprint(s), then the corresponding keys will be made available under https://people.apache.org/keys/ within a few hours. Additionally, qpid project requires adding a public key into https://dist.apache.org/repos/dist/release/qpid/KEYS.

Maven

Maven is used to build and manage Qpid Java project. 3.x version of maven needs to be installed and the development environment should be setup as described at Publishing of Maven Artifacts.

Please, note that repository id (server id) in setting xml should be apache.releases.https. Using different id would result in failures to publish release artifacts into staging maven repo.

Java

JDK 1.7 is required to compile java classes. Install latest 1.7 JDK. At the moment of writing this document 1.7.0_80 JDK was the latest one.

Git

Sources are kept in a Git repository. Thus a git client is required.

Major/Minor version release

  1. Checkout Qpid sources from trunk using git client.

    git clone https://git-wip-us.apache.org/repos/asf/qpid-broker-j.git qpid-broker-j
    cd ./qpid-broker-j
    
  2. Run RAT tool to verify that all source files have license headers

    mvn  apache-rat:check

    Check that any images don't have a non-free ICC profile:

    find . -regextype posix-extended -iregex '.*\.(jpg|png|ico|tif)' -exec sh -c 'identify -verbose "$0" | grep -i copyright && echo "$0"' {} \;
  3. Check that build completes successfully using profile apache-release

    mvn clean install -Papache-release -DskipTests
    

    The gpg plugin will prompt for the password of PGP  signing key. If password is asked for every release artifact, then gpg2 should be configured to use. The easiest way to configure gpg2 is to add an active profile with pgp plugin settings into settings.xml:

    ~/.m2/settings.xml
    <settings>
      <servers>    
        <server>
          <id>apache.snapshots.https</id>
          <username>YOUR_APACHE_SVN_USERNAME</username>
          <password>YOUR_APACHE_SVN_PASSWORD</password>
        </server>
        <server>
          <id>apache.releases.https</id>
          <username>YOUR_APACHE_SVN_USERNAME</username>
          <password>YOUR_APACHE_SVN_PASSWORD</password>
        </server>
    
        <!-- optional -->
        <server>
          <id>gpg.passphrase</id>
          <passphrase>{XXXX}</passphrase>
        </server>
     </servers>
      
      <profiles>
        <profile>
          <id>apache-release</id>
          <properties>
            <gpg.keyname>A2889D83</gpg.keyname>
            <gpg.executable>gpg2</gpg.executable>
          </properties>
        </profile>
      </profiles>
    </settings>
  4. Add license headers to the files which do not have licenses. Update RAT excludes if required.

  5. Verify third party licenses

    mvn -Pdependency-check prepare-package -DskipTests
    

    The check should finish successfully. Otherwise, dependencies with not complaint licenses should be resolved before taking next release step.

    When new dependencies are added or changed the dependency verification files needs to be updated. In order to do so, run the command above with flag -Ddependency-change-verification=true

  6. Build alpha.

    1. Making an alpha build is optional and can be skipped if required. Alpha does not requires branching. The following chain of maven commands can be used to build and deploy alpha into staging repo
      Example of building 6.0.0-alpha

      mvn versions:set -DnewVersion=6.0.0-alpha ; mvn clean install deploy -Papache-release ; mvn versions:revert
      

      maven versions plugin is used to change version and revert it back after build and deploy

    2. On successful completion the build is deployed into staging repository, which needs to be closed in order to be available. Log into Apache Nexus UI, select the repository under "Staging Repository" and click Close button to close staging repository to prevent publishing of any new artifact. After closing, a permanent link to the staging repository will be available.
    3. Send an email into users@qpid.apache.org about alpha availability with a link to the staging repository.
    4.  Do not forget to delete staging repo after building RC or beta build. It requires logging into Apache Nexus UI, selecting the repository and clicking "Drop" button.
  7. Check JIRA system for any unresolved JIRAs for the release and notify assigned developers to take actions on uncompleted JIRAs
  8. Cut the branch using release:branch. Please, refer maven release plugin documentation for more details. For example, the following command was used to cut 6.0.x branch

    mvn release:branch -DbranchName=6.0.x -DupdateBranchVersions=false -DupdateWorkingCopyVersions=true  -DautoVersionSubmodules=true
    

    As part of execution command above maven asks about new version of the trunk sources and changes the version to provided one.

  9. Build beta if required following instructions in step 5 on branched sources
  10. Build RC

    1. Checkout branch sources, for example, 6.0.x branch is checked out as below

      git clone -b 6.0.x https://git-wip-us.apache.org/repos/asf/qpid-broker-j.git 6.0.x
      cd 6.0.x
      
    2. If it is not a first RC, remove previous tag from git

      git push --delete origin x.y.z
      

      where x.y.z is a tag version

    3. Cut the tag using maven:prepare

      mvn release:clean
      mvn release:prepare -Papache-release,java-mms.0-9  -DautoVersionSubmodules=true -DpreparationGoals=test
      

      Release plugin will ask about new release version, tag name and new development version. Enter the same values for version and tag

      On successful execution a tag with a provided name will be created, the tag version will be set to the specified release version and development version on the branch will be changed to the provided one

    4. Build the RC and publish release artifacts into maven staging repo

      mvn release:perform -Papache-release,java-mms.0-9 -Darguments="-DskipTests"

      release:perform will build release artifacts and deploy them into staging repo. Note that this will do a clean checkout so it might take a while.

    5. The staging maven repository needs to be closed. Log into Apache Nexus UI, select the repository under "Staging Repository" and click Close button to close staging repository for any publishing of artifacts. After closing, a permanent link to the staging repository will be available.
    6. Copy source and binary bundles and their signatures/checksum files from the nexus staging repository into qpid dev staging area at https://dist.apache.org/repos/dist/dev/qpid/java/ under the sub-folder with the same name as tag. Binary bundles  and their signatures/checksum files need to be put into sub-folder with name binaries. (Not doing so would break the site). Manually rename the source artefact to keep with the source artefact name consistent.

      Use curl or wget to download all broker and client tar.gz and zip bundles and their signatures from maven staging repo like so:

      version=6.2.1
      root=https://repository.apache.org/content/repositories/orgapacheqpid-1103
      mkdir binaries
      
      for i in "" .asc; do
        curl -O  $root/org/apache/qpid/qpid-java-build/$version/qpid-java-build-$version.tar.gz$i
        mv qpid-java-build-$version.tar.gz${i} qpid-java-$version.tar.gz${i}
      done
      
      sha512sum qpid-java-${version}.tar.gz > qpid-java-${version}.tar.gz.sha512
      
      cd binaries
      for i in broker client ; do for j in zip tar.gz; do for k in "" .asc ; do curl -O  $root/org/apache/qpid/qpid-$i/$version/qpid-$i-$version-bin.$j$k; done; done; done
      for i in broker client ; do for j in zip tar.gz; do sha512sum  qpid-${i}-${version}-bin.${j} > qpid-${i}-${version}-bin.${j}.sha512 ; done; done
      
      cd ..
      
      
    7. Send an email into users@qpid.apache.org about RC availability with links to the maven staging repository and qpid dev staging area folder containing source and binary bundles

  11. If RC is OK and voting passes, publish release artifacts:
    1. send a email to users@qpid.apache.org to close the vote. This should include the number of binding and non-binding votes, the result, and a link to the voting thread (use Apache services (this or
      this).
    2. promote maven staging artifacts from staging repository into the world by pressing Release button in Apache Nexus UI.
    3. copy source and binary bundles and their signatures/checksum files form dev staging are into release distribution area. For example, the commands below copy dev 6.0.0-rc5 artifacts into final 6.0.0

      svn cp -m "Publish 6.0.0 release artifacts" https://dist.apache.org/repos/dist/dev/qpid/java/6.0.0-rc5 https://dist.apache.org/repos/dist/release/qpid/java/6.0.0

      If voting does not pass, resolve found issues, drop staging repository, delete svn tag and repeat instructions from step 9 until voting passes.

  12. Wait for 24 hours after closing the vote
  13. Update Qpid web site Qpid Java Component pages and publish new release documentation following instructions here.
    Java 8 could be required for latest fop/docbook dependencies. Here are sample commands which could be used to create 6.0.3 release pages on the website based on the 6.0.3 tag.

    git clone https://git-wip-us.apache.org/repos/asf/qpid-site.git site
    cd ./site
    make gen-java-release RELEASE=6.0.3 ISSUES_RELEASE=qpid-java-6.0.3
    vim ./input/releases/qpid-java-6.0.3/release-notes.md # headline major enhancements and new features
    vim ./input/_transom_config.py              # Update the current release pointer
    vim ./input/releases/index.md               # Add current release, move the previous
    make render
    make check-links
    make publish
    git add input/
    git add content/
    git commit -m "Update site for Qpid Java release 6.0.3"
    git push


  14. Mark release as released in JIRA and close any unresolved JIRAs if required
  15. Send the release notification email into users@qpid.apache.orgdev@qpid.apache.org and announce@apache.org

    Note, In order to send messages into announce@apache.org one need to send the mail with the From field set to one's apache.org address. Gmail can be set-up to do so via use of the ASF mail relay. The details how to set up apache account to use ASF mail relay can be found in the following resources
    https://blogs.apache.org/infra/entry/committers_mail_relay_service
    https://reference.apache.org/committer/email#sendingemailfromyourapacheorgemailaddress
    http://gmailblog.blogspot.co.uk/2009/07/send-mail-from-another-address-without.html

  16. Remove the previous release binaries from  https://dist.apache.org/repos/dist/release/qpid/java when a new one is announced
  17. Create jenkins jobs for new major/minor version

Bugfix release procedure

Execute steps 1-7 and 9-16 from Major release procedure on branch sources.

  • No labels