Apache NiFi Release Guidelines

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

The objective

Our aim is to produce an official Apache release from an existing release branch.

Background Material

Terms

High level flow of a release

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/nifi-${NIFI_VERSION}" is seen in an instruction or email template it should be replaced with
"/tmp/src/nifi-0.7.0" when working the release of "Apache NiFi 0.7.0".

NOTE: The next version should be the next minor version if the release is based on a major version development branch (e.g main
or 0.x). The next version should be the next incremental version if the release is based on a minor version development branch (e.g
support/nifi-1.1.x or support/nifi-0.7.4). If this is the first incremental release (e.g. 1.2.1) for a minor release line the support
branch may need to be created.

What to validate and how to validate a release

The following is a list of the sorts of things that will be validated and are the basics to check
when evaluating a release for a vote.

This list is reflected in the Release Vote and Release Helper Guide emails that are sent once the release has been
staged in the Git and Nexus repositories.

The Release Process

The release process includes steps to be performed by the Release Manager as well as the
Apache NiFi developer community.

Step 1. Configure the build environment (RM and community)

  1. Follow the steps outlined in the Quickstart Guide to prepare the development system.
  2. Confirm that the local Git workspace is configured with an origin remote pointing to the RM's personal fork of the
    NiFi source and an "ASF" remote pointing to the Apache Git Repository for NiFi. 
    $ git remote -v
asf https://gitbox.apache.org/repos/asf/nifi.git (fetch)
asf https://gitbox.apache.org/repos/asf/nifi.git (push)
origin  https://github.com/${RM_USERID}/nifi.git (fetch)
origin  https://github.com/${RM_USERID}/nifi.git (push)
    Additional remotes will not cause a problem if these two are correct. Other configurations are perfectly
    acceptable but the appropriate adjustments to the steps in this guide must be made by the release manager.
  3. Confirm that source code can be checked out for the branch being released. 
    git checkout ${BRANCH}
  4. Confirm that the entire application builds correctly in the build environment.

Step 2. Prepare and stage the release (RM)

  1. Create a JIRA ticket for the release tasks for version ${NIFI_VERSION}.
    The resulting JIRA ticket number is referred to as ${JIRA_TICKET} in this guide.
  2. Create the next version in JIRA, if it doesn't already exist, so work can continue towards that release.
  3. Create meaningful release notes for this version if not already created. Enter them here on
    the NiFi wiki.
  4. Create a new branch off 'main' named after the JIRA ticket. 
    $ git checkout -b ${JIRA_TICKET}-RC${RC} ${BRANCH}
  5. 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 for Java 8 for NiFi version 1.x and later. 
      $ export MAVEN_OPTS="-Xms1024m -Xmx3076m"
    • And these work for Java 7 for NiFi version 0.x. 
      $ export MAVEN_OPTS="-Xms1024m -Xmx3076m -XX:MaxPermSize=256m"
  6. Ensure your settings.xml has been updated to include a signed_release profile and a <server> entry for
    "repository.apache.org" as shown below. Steps to configure and encrypt Maven passwords.
    There are other ways to ensure your PGP key is available for signing as well. 
        <profile>
        <id>signed_release</id>
        <properties>
            <mavenExecutorId>forked-path</mavenExecutorId>
            <gpg.keyname>${RM_USERID}@apache.org</gpg.keyname>
            <gpg.passphrase>GPG passphrase</gpg.passphrase>
        </properties>
    </profile>

    <servers>
        <server>
            <id>repository.apache.org</id>
            <username>${RM_USERID}</username>
            <password>ENCRYPTED PASSWORD HERE</password>
        </server>
    </servers>
  7. Ensure the the full application builds and all tests work by executing a parallel (multi-threaded) build. 
    $ mvn -T 2.5C clean install -Pinclude-grpc
  8. Startup and test the application with from the root source folder. After a few seconds, NiFi should be up and
    running at http://localhost:8080/nifi. 
    $ cd nifi-assembly/target/nifi-${NIFI_VERSION}-bin/nifi-${NIFI_VERSION}
$ bin/nifi.sh start
  9. Evaluate and ensure the appropriate license headers are present on all source files.
  10. 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.)
  11. Build the project with the contrib-check profile enabled to validate contribution expectations and find any
    problems that must be addressed before proceeding. 
    $ mvn install -Pcontrib-check,include-grpc
  12. Verify and update if necessary to ensure Docker version information points to the next release version. For instance, set correct release versions in various Dockerfile files found in the codebase. There are approximately 5 to update as of version 1.16.

Step 3. Perform the release (RM)

  1. Now its time to have maven prepare the release with this command.
    NOTE: gpg will be invoked during this step, which will need to prompt you for a password. From the command line, use
    export GPG_TTY=$(tty) to allow gpg to prompt you.

    $ mvn --batch-mode release:prepare \
    -Psigned_release,include-grpc \
    -DscmCommentPrefix="${JIRA_TICKET}-RC${RC} " \
    -Dtag="nifi-${NIFI_VERSION}-RC${RC}" \
    -DreleaseVersion="${NIFI_VERSION}" \
    -DdevelopmentVersion="${NEXT_VERSION}" \
    -Darguments="-DskipTests"

  2. Review the release preparation results. If problems are found $ mvn release:rollback will reset the changes, or
    it may be necessary to run $ mvn release:clean to get the project to a state where it can be rebuilt.

  3. If the preparation without problems, it is time to perform the release and deploy artifacts to staging.

    $ mvn release:perform \
    -Psigned_release,include-grpc \
    -DscmCommentPrefix="${JIRA_TICKET}-RC${RC} " \
    -Darguments="-DskipTests"

    When this completes the artifacts have been released to the Apache Nexus staging repository, a local release branch
    has been created and there should the staging repository ID returned in a log entry like this.

    [INFO]  * Closing staging repository with ID "orgapachenifi-1088"

    This staging repository ID is referred to by ${STAGING_REPO_ID} in this release guide.

  4. Browse to the Apache Staging Repository and
    login with your Apache committer credentials and you should see the newly created staging repository listed. If you
    click on that you can inspect the various staged artifacts.

  5. Validate that all the various aspects of the staged artifacts appear correct

    • Download the sources and signature at the following URL. Do they compile cleanly? If the result is a build does it execute? We download the sources and signature from the nexus artifacts so that these sources and signature match what we put in dist and thus all signatures and such match. If you pull the sources from your local build it will differ and can create confusion during RC validation. These are the first two primary artifacts you need for the voting (the sources and the signature). You'll gather other artifacts and signatures and generate hashes below.
      wget https://repository.apache.org/service/local/repositories/orgapachenifi-nnnn/content/org/apache/nifi/nifi/${NIFI_VERSION}/nifi-${NIFI_VERSION}-source-release.zip
      wget https://repository.apache.org/service/local/repositories/orgapachenifi-nnnn/content/org/apache/nifi/nifi/${NIFI_VERSION}/nifi-${NIFI_VERSION}-source-release.zip.asc
    • Validate the hashes match.
    • Validate that the sources contain no unexpected binaries.
    • Validate the signature for the build and hashes. Verifying a release signature.
    • Validate the LICENSE/NOTICE/Headers.
    • Validate that the README is present and provides sufficient information to build and if necessary execute.

  6. The validated artifacts all look good then push the branch to origin release branch to the ASF repository.

    $ git push asf ${JIRA_TICKET}-RC${RC}

    From this branch, the ${RC_TAG_COMMIT_ID} will be the 40 byte commit hash with the comment ${JIRA_TICKET}-RC${RC} prepare release nifi-${NIFI_VERSION}-RC${RC}

  7. Push the tag created by the release:prepare step to the ASF repository.

    git push asf nifi-${NIFI_VERSION}-RC${RC}

  8. Create the signature and hashes for the source release and convenience binary files. You take the source release and signature from steps above. You grab the other conveniece binaries from your local build directories.

    1. ASCII armored GPG signatures (--digest-algo=SHA512 select the SHA512 hash algorithm). Configure GPG to always prefer stronger hashes. 
      $ gpg -a -b --digest-algo=SHA512 nifi-${NIFI_VERSION}-bin.tar.gz          # produces nifi-${NIFI_VERSION}-bin.tar.gz.asc
$ gpg -a -b --digest-algo=SHA512 nifi-${NIFI_VERSION}-bin.zip             # produces nifi-${NIFI_VERSION}-bin.zip.asc
$ gpg -a -b --digest-algo=SHA512 nifi-toolkit-${NIFI_VERSION}-bin.zip     # produces nifi-toolkit-${NIFI_VERSION}-bin.zip.asc
$ gpg -a -b --digest-algo=SHA512 nifi-toolkit-${NIFI_VERSION}-bin.tar.gz  # produces nifi-toolkit-${NIFI_VERSION}-bin.tar.gz.asc
    2. Generate SHA256 hash summaries. 
      $ shasum -a 256 nifi-${NIFI_VERSION}-source-release.zip | cut -d" " -f1 >  nifi-${NIFI_VERSION}-source-release.zip.sha256
$ shasum -a 256 nifi-${NIFI_VERSION}-bin.tar.gz | cut -d" " -f1 >  nifi-${NIFI_VERSION}-bin.tar.gz.sha256
$ shasum -a 256 nifi-${NIFI_VERSION}-bin.zip | cut -d" " -f1 >  nifi-${NIFI_VERSION}-bin.zip.sha256
$ shasum -a 256 nifi-toolkit-${NIFI_VERSION}-bin.zip | cut -d" " -f1 >  nifi-toolkit-${NIFI_VERSION}-bin.zip.sha256
$ shasum -a 256 nifi-toolkit-${NIFI_VERSION}-bin.tar.gz | cut -d" " -f1 >  nifi-toolkit-${NIFI_VERSION}-bin.tar.gz.sha256
    3. Generate SHA512 hash summaries. 
      $ shasum -a 512 nifi-${NIFI_VERSION}-source-release.zip | cut -d" " -f1 >  nifi-${NIFI_VERSION}-source-release.zip.sha512
$ shasum -a 512 nifi-${NIFI_VERSION}-bin.tar.gz | cut -d" " -f1 >  nifi-${NIFI_VERSION}-bin.tar.gz.sha512
$ shasum -a 512 nifi-${NIFI_VERSION}-bin.zip | cut -d" " -f1 >  nifi-${NIFI_VERSION}-bin.zip.sha512
$ shasum -a 512 nifi-toolkit-${NIFI_VERSION}-bin.zip | cut -d" " -f1 >  nifi-toolkit-${NIFI_VERSION}-bin.zip.sha512
$ shasum -a 512 nifi-toolkit-${NIFI_VERSION}-bin.tar.gz | cut -d" " -f1 >  nifi-toolkit-${NIFI_VERSION}-bin.tar.gz.sha512

  9. For reviewing of the release candidate, commit the source release and convenience binaries files along with their
    hashes and signatures to https://dist.apache.org/repos/dist/dev/nifi/nifi-${NIFI_VERSION}. There should be in total 20 files (5 primary artifacts, 5 signatures, 5 sha256, 5 sha512).

Step 4. Error recovery (RM)

If anything isn't correct about the staged artifacts you can drop the staged repo from repository.apache.org and delete
the local tag in git. If you also delete the local branch and clear your local maven repository under org/apache/nifi
then it is as if the release never happened. Before doing that though try to figure out what went wrong so the Release
Guide can be updated or corrected if necessary.

So, as has been described here you can test the release process until you get it right. The mvn versions:set -Pinclude-grpc and
mvn versions:commit -Pinclude-grpc commands can come in handy to help do this so you can set versions to something clearly release
test related.

Step 5. Release Vote (RM and community)

After the release source and artifacts are staged in the repositories it's time for the RM to send a release vote to the
NiFi community.

Once the release vote is called for, members of the NiFi developer community have 72 hours to evaluate the RC and
cast their vote by replying to the "[VOTE] Release ..." email sent by the RM.

NOTE: The release vote is majority rule vote that must include at least 3 binding +1 votes Apache NiFi PMC members
and more positive than negative binding votes.

  1. RM sends a vote request email to the NiFi Developers Mailing List.

    • TO: dev@nifi.apache.org
    • FROM: ${RM_USERID}@apache.org
    • SUBJECT: [VOTE] Release Apache NiFi ${NIFI_VERSION}
    Hello,

I am pleased to be calling this vote for the source release of Apache NiFi nifi-${NIFI_VERSION}.

The source zip, including signatures, digests, etc. can be found at:
https://repository.apache.org/content/repositories/orgapachenifi-nnnn

The source being voted upon and the convenience binaries can be found at:
https://dist.apache.org/repos/dist/dev/nifi/nifi-${NIFI_VERSION}/

A helpful reminder on how the release candidate verification process works:
https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate

The Git tag is nifi-${NIFI_VERSION}-RC${RC}
The Git commit ID is ${RC_TAG_COMMIT_ID}
https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=${RC_TAG_COMMIT_ID}

Checksums of nifi-x.y.z-source-release.zip:
SHA256: <64-CHAR-SHA256SUM-HASH>
SHA512: <128-CHAR-SHA512SUM-HASH>

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/${RM_USERID}.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

8 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329307

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version${NIFI_VERSION}

The vote will be open for 72 hours.
Please download the release candidate and evaluate the necessary items including checking hashes, signatures, build
from source, and test. Then please vote:

[ ] +1 Release this package as nifi-${NIFI_VERSION}
[ ] +0 no opinion
[ ] -1 Do not release this package because...

  2. Developers in the community review the release candidate and reply to the vote email with their vote.

  3. After 72 hours if

    • at least 3 binding (PMC members) cast +1 votes, and
    • the positive binding votes out number any negative binding votes

    the vote passes and the release candidate is officially released. If the vote does not pass, corrections are made
    on the release branch and a new release candidate is put forward for a new vote.

  4. RM sends vote result email.

    • TO: dev@nifi.apache.org
    • FROM: ${RM_USERID}@apache.org
    • SUBJECT: [RESULT][VOTE] Release Apache NiFi ${NIFI_VERSION}
    Apache NiFi Community,

I am pleased to announce that the ${NIFI_VERSION} release of Apache NiFi passes with
    X +1 (binding) votes
    Y +1 (non-binding) votes
    0 0 votes
    0 -1 votes

Thanks to all who helped make this release possible.

Here is the PMC vote thread: ${VOTE_THREAD_URL}

Step 6. Finalize the Release

After the vote is complete and the release is approved, these steps complete the release process.

  1. Move convenience binaries and related artifacts from dist/dev to dist/release:

    $ svn move -m "${JIRA_TICKET}" https://dist.apache.org/repos/dist/dev/nifi/nifi-${NIFI_VERSION} https://dist.apache.org/repos/dist/release/nifi/${NIFI_VERSION}

  2. In repository.apache.org go to the staging repository and select release and follow the instructions on the site.

  3. Merge the release branch into main. (this will result in a merge commit)

    $ git checkout main
$ git merge --no-ff ${JIRA_TICKET}-RC${RC}
$ git push asf main

  4. Update Docker version information to point to the next release. For instance, if the next version applied by Maven is 1.3.0-SNAPSHOT, these values should be updated to 1.3.0. This currently consists of three files:

  5. Commit and push the dockerhub module updates to the ASF repository:

    git commit -m "${JIRA_TICKET} Updated dockerhub module for next release"
git push asf main

  6. Update the NiFi website to point to the new download(s). Remove older release artifacts from download page (leave
    the current release and the previous one). For the release just previous to this new one change the links to point to
    the archive location. See current page as an example of the needed URL changes.

  7. Remove artifacts other than the current/new release from the dist/SVN storage https://dist.apache.org/repos/dist/release/nifi/ Confirm the artifacts you deleted are present in apache archive where ASF keeps all releases forever http://archive.apache.org/dist/nifi/

  8. Update the Migration Guide on the Wiki.

  9. If the release is on the latest development line, update the NiFi website documentation pages to match the release. (This section will be updated when a complete plan for maintaining different versions of the guides, API docs, etc. is available.)

    1. Run the NiFi ${NIFI_VERSION}
    2. Pull down the documentation by running wget -prk http://${host}:${port}/nifi-docs/documentation
    3. Rename the directory to avoid escaping characters by running mv -v ${host}\:${port} ${NIFI_VERSION}-docs
    4. Rename the file index file that was generated by running mv -v ${NIFI_VERSION}-docs/nifi-docs/documentation ${NIFI_VERSION}-docs/nifi-docs/index.html
    5. Merge the existing documentation (i.e. version n-1, n-2, etc.) with the new version documentation (rsync is used to avoid issues with recursion and merging)
      1. Checkout the existing Subversion repository containing the docs by running svn co https://svn.apache.org/repos/asf/nifi/site/trunk/docs svn-docs
      2. Replace the nifi directory (site JS assets, images, etc.) by running rsync -av ${NIFI_VERSION}-docs/nifi/ svn-docs/nifi/
      3. Replace the nifi-docs/... directories (guides, API docs, JS/CSS assets, images, etc. but excluding component docs) by running rsync -av --delete --exclude='components' ${NIFI_VERSION}-docs/nifi-docs/ svn-docs/nifi-docs/ (the trailing slashes are important)
      4. Merge the component documentation by running rsync -av ${NIFI_VERSION}-docs/nifi-docs/components/ svn-docs/nifi-docs/components/
      5. (Optional) Check the status by running svn st svn-docs
      6. Add the new files to version control by running cd svn-docs && svn add . --force
      7. Commit the changes by running svn ci -m "Added ${NIFI_VERSION} docs to NiFi site."

  10. In JIRA mark the release version as 'Released' and 'Archived' through 'version' management in the 'administration' console.

  11. Ensure the release artifacts are successfully mirrored to the archive, specifically https://archive.apache.org/dist/nifi/${NIFI_VERSION}/nifi-${NIFI_VERSION}-bin.tar.gz.
    This convenience binary file is the basis for our Docker build and is needed in place before the released tag is pushed to the repository. If there were any
    issues with the above listed file not being available, it may be necessary to reach out to the ASF Infra team to adjust file size limits to accommodate larger artifacts.
    NOTE: The Docker build is triggered by pushing the signed tag in the next step. The release artifacts must be present
    in the archive before continuing.

  12. Create a proper signed tag of the released codebase based on the RC Tag created during the Maven release process.
    NOTE: gpg will be invoked during this step, which will need to prompt you for a password. From the command line, use
    export GPG_TTY=$(tty) to allow gpg to prompt you.

    $ git tag -s rel/nifi-${NIFI_VERSION} -m "${JIRA_TICKET} Signed release tag for approved release of NiFi ${NIFI_VERSION}" ${RC_TAG_COMMIT_ID}

    For instructions on setting up to sign your tag see here.

  13. Push the release tag to the official ASF repository.

    $ git push asf rel/nifi-${NIFI_VERSION}

  14. Verify that the Docker build began at the Build Status page. If the build does not take place soon after the release tag was pushed, it may be necessary to contact ASF Infra to ask for assistance and the job to be triggered again.

  15. Update the release notes with the final date of the release.

  16. After the release has been complete for 24 hours send the release announcement.