Versions Compared

Old Version 6

changes.mady.by.user Aldrin Piri

Saved on

compared with

New Version Current

changes.mady.by.user Jeremy Dyer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The purpose of this document is to capture and describe the steps involved in producing an official release of Apache NiFi MiNiFI for both Java and C++ versions. It is written specifically to someone acting in the capacity of a Release Manager (RM).

...

  • The community is contributing to a series of JIRA tickets assigned to the next release
  • The number of tickets open/remaining for that next release approaches zero
  • A member of the community suggests a release and initiates a discussion
  • Someone volunteers to be an RM for the release (can be a committer but apache guides indicate preference is a PMC member)
  • A release candidate is put together and a vote sent to the team.
  • If the NiFi community rejects the vote the issues noted are resolved and another RC is generated
  • If the NiFi community accepts the vote then the release is 'releasable' and can be placed into the appropriate 'dist' location, maven artifacts released from staging.

The mechanics of the release

Prepare your environment

Follow the steps outlined in the Quickstart Guide

At this point you're on the latest 'master' branch and are able to build the entire application

...

Create the next version in JIRA if necessary so work can continue towards that release.

Create meaningful release notes for this version if not already created. Enter them here

Create new branch off 'master' named after the JIRA ticket. Here we'll use a branch off of 'master' with git checkout -b NIFI-270-RC1

Verify that Maven has sufficient heap space to perform the build tasks. Some plugins and parts of the build consumes a surprisingly large amount of space. These settings have been shown to work MAVEN_OPTS="-Xms1024m -Xmx3076m -XX:MaxPermSize=256m"

...

Variable reference substitutions


Throughout this guide, references must be made to names and values that will vary from release to release. For clarity those variable values have been written like Bash variable references. When a term like "/tmp/src/minifi-${MINIFI_VERSION}" is seen in an instruction or email template it should be replaced with "/tmp/src/minifi-0.5.0" when working the release of "Apache NiFi MiNiFi 0.5.0".

  • Subtitutions used in tasks and email templates

    Reference            Example value       Description
    =========            ==============      ===========
    ${BRANCH}            0.5.0-SNAPSHOT      the development branch on which the release is based.
    ${MINIFI_VERSION}      0.5.0               the version currently in development on the release branch.
    ${NEXT_VERSION}      0.6.0-SNAPSHOT      the future version for development on the release branch.
    ${JIRA_TICKET}       MINIFI-458           the JIRA ticket created by the release manager for the release tasks.
    ${RC}                2                   the Release Candidate index start at 1 for the first release candidate.
    ${RC_TAG_COMMIT_ID}                      the commit ID of the RC tag created during the Maven release process.
    ${RM_USERID}         johndoe             the Apache account ID of Release Manager.
    ${RELEASE_TAG}       rel/minifi-0.5.0      the Git repository tag for the source code as released.
    ${VOTE_THREAD_URL}   [0.5.0 vote thread][050-rc2-vote]   the URL for the Apache Pony Mail archive of the release vote thread.

    To be practical but avoid confusion with future release details, these example values reflect the previous release MiNiFi 0.5.0 RC2 release details.

The mechanics of the release

Prepare your environment

Follow the steps outlined in the Quickstart Guide

At this point you're on the latest 'master' branch and are able to build the entire application


  • Create a JIRA ticket for the release tasks and use that ticket number for the commit messages. For example we'll consider MINIFI-458 as our ticket. Also have in mind the release version you are planning for. For example we'll consider '0.5.0'.
  • Create the next version in JIRA if necessary so work can continue towards that release.
  • Create meaningful release notes for this version if not already created. Enter them here
  • Create new branch off 'master' named after the JIRA ticket. Here we'll use a branch off of 'master' with git checkout -b MINIFI-458-RC1

Ensure your Maven settings.xml has been updated as shown below. There are other ways to ensure your PGP key is available for signing as well

Code Block
...
        <profile>
           <id>signed_release</id>
           <properties>
               <mavenExecutorId>forked-path</mavenExecutorId>
               <gpg.keyname>YOUR GPG KEY ID HERE</gpg.keyname>
               <gpg.passphrase>YOUR GPG PASSPHRASE HERE</gpg.passphrase>
           </properties>
       </profile>
       ...
       <servers>
          <server>
              <id>repository.apache.org</id>
              <username>YOUR USER NAME HERE</username>
              <password>YOUR MAVEN ENCRYPTED PASSWORD HERE</password>
          </server>
       </servers>
       ...

        ...
        <profile>
           <id>signed_release</id>
           <properties>
               <mavenExecutorId>forked-path</mavenExecutorId>
               <gpg.keyname>YOUR GPG KEY ID HERE</gpg.keyname>
               <gpg.passphrase>YOUR GPG PASSPHRASE HERE</gpg.passphrase>
           </properties>
       </profile>
       ...
       <servers>
          <server>
              <id>repository.apache.org</id>
              <username>YOUR USER NAME HERE</username>
              <password>YOUR MAVEN ENCRYPTED PASSWORD HERE</password>
          </server>
       </servers>
       ...

Ensure the the full application build and tests all work by executing mvn -T 2.5C clean install for a parallel build. Once that completes you can startup and test the application by cd nifi-assembly/target then run bin/nifi.sh start in the nifi build. The application should be up and running in a few seconds at http://localhost:8080/nifirun "bin/minifi.sh start" in the MiNiFi build.

Evaluate and ensure the appropriate license headers are present on all source files. Ensure LICENSE and NOTICE files are complete and accurate.
Developers should always be keeping these up to date as they go along adding source and modifying dependencies to keep this burden manageable.
This command mvn install -Pcontrib-check should be run as well to help validate. If that doesn't complete cleanly it must be addressed.

...

If all looks good then push the branch to origin git push origin NIFIMINIFI-270458

For reviewing of the release candidate - The sources, hashes, signature, and the convenience binary, its hashes, and signature should be placed here:

- https://dist.apache.org/repos/dist/dev/nifiminifi-0.5.0.1/


For each convenience binaryeach convenience binary

- Generate ascii armored detached signature by running `gpg -a -b --digest-algo=SHA512 nifi-0.0.1-bin.tar.gz`
- Generate md5ascii armored hashdetached summarysignature by running `md5sum`gpg nifi-0.0.1-bin.tar.gz | awk '{ printf substr($0,0,32)}' >  -a -b --digest-algo=SHA512 nifi-0.0.1-bin.tar.gz.md5`gz`
- Generate sha1 hash summary by running `sha1sum nifi-0.0.1-bin.tar.gz | awk '{ printf substr($0,0,40)}' >  nifi-0.0.1-bin.tar.gz.sha1`
- Upload the bin, asc, sha1, md5 for each binary convenience build to the same location as the source release

...