Page History

...

1. Release Manager’s GPG key is published to dist.apache.org
2. Release Manager’s GPG key is configured in git configuration
3. Release Manager has org.apache.flink listed under Staging Profiles in Nexus
4. Release Manager’s Nexus User Token is configured in settings.xml
5. JIRA release item for the subsequent release has been created
6. There are no release blocking JIRA issues
7. Release Notes in JIRA have been audited and adjusted
8. Release branch has been created
9. Originating branch has the version information updated to the new version

Build a release candidate

The core of the release process is the build-vote-fix cycle. Each cycle produces one release candidate. The Release Manager repeats this cycle until the community approves one release candidate, which is then finalized.

Build and stage Java artifacts with Maven

Set up a few environment variables to simplify Maven commands that follow. This identifies the release candidate being built. Start with RC_NUM equal to 1 and increment it for each candidate.

RC_NUM="1"
TAG="v${VERSION}-RC${RC_NUM}"

Use Maven release plugin to build the release artifacts, as follows:

mvn release:prepare \
    -Dresume=false \
    -DreleaseVersion=${VERSION} \
    -Dtag=${TAG} \
    -DupdateWorkingCopyVersions=false

Use Maven release plugin to stage these artifacts on the Apache Nexus repository, as follows:

mvn release:perform

Review all staged artifacts. They should contain all relevant parts for each module, including pom.xml, jar, test jar, source, test source, javadoc, etc. Carefully review any new artifacts.

Close the staging repository on Apache Nexus. When prompted for a description, enter “Apache Flink, version X, release candidate Y”.

Stage source release on dist.apache.org

Copy the source release to the dev repository of dist.apache.org.

1. If you have not already, check out the Flink section of the dev repository on dist.apache.org via Subversion. In a fresh directory:

   Code Block
   language bash
   svn co https://dist.apache.org/repos/dist/dev/flink

2. Make a directory for the new release:

   Code Block
   language bash
   mkdir flink/${VERSION} cd flink/${VERSION}

   Copy and rename the Beam source distribution, hashes, and GPG signature:

   Code Block
   language bash
   cp ${FLINK_ROOT}/target/flink-${VERSION}-source-release.tar.gz . cp ${FLINK_ROOT}/target/flink-${VERSION}-source-release.tar.gz.asc .

3. Create hashes for source files 

   Code Block
   language bash
   sha512sum flink-${VERSION}-source-release.tar.gz > flink-${VERSION}-source-release.tar.gz.sha md5sum flink-${VERSION}-source-release.tar.gz > flink-${VERSION}-source-release.tar.gz.md5

4. Add and commit all the files.

    svn add flink/${VERSION}
    svn commit
   

5. Verify that files are present.

Propose a pull request for website updates

The final step of building the candidate is to propose a website pull request.

Start by updating the variables for the latest released version in the top-level _config.yml, and list the new release in downloads.md, linking to the source code download and the Release Notes in JIRA. Also add a new blog entry announcing the release in _posts.

Finally, propose a pull request with these changes. (Don’t merge before finalizing the release.)

Checklist to proceed to the next step

1. Maven artifacts deployed to the staging repository of repository.apache.org
2. Source distribution deployed to the dev repository of dist.apache.org
3. Website pull request proposed to list the release

You can (optionally) also do additional verification by:

1. Check hashes (e.g. md5sum -c *.md5 and sha512sum -c *.sha1)
2. Check signatures (e.g. gpg --verify flink-1.2.3-source-release.tar.gz.asc flink-1.2.3-source-release.tar.gz)
3. grep for legal headers in each file.