Page History

...

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

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

...

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 BeamFlink 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.

   Code Block
   language bash
   svn add flink/${VERSION} svn commit

5. Verify that files are present.

...

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.

Vote on the release candidate

Once you have built and individually reviewed the release candidate, please share it for the community-wide review. Please review foundation-wide voting guidelines for more information.

Start the review-and-vote thread on the dev@ mailing list. Here’s an email template; please adjust as you see fit.

From: Release Manager
To: dev@flink.apache.org
Subject: [VOTE] Release 1.2.3, release candidate #3

Hi everyone,
Please review and vote on the release candidate #3 for the version 1.2.3, as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)


The complete staging area is available for your review, which includes:
* JIRA release notes [1],
* the official Apache source release to be deployed to dist.apache.org [2], which is signed with the key with fingerprint FFFFFFFF [3],
* all artifacts to be deployed to the Maven Central Repository [4],
* source code tag "release-1.2.3-rc3" [5],
* website pull request listing the new release and adding announcement blog post [6]. 

The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes.

Thanks,
Release Manager

[1] link
[2] link
[3] https://dist.apache.org/repos/dist/release/beam/KEYS
[4] link
[5] link
[6] link

If there are any issues found in the release candidate, reply on the vote thread to cancel the vote. There’s no need to wait 72 hours. Proceed to the Fix Issues step below and address the problem. However, some issues don’t require cancellation. For example, if an issue is found in the website pull request, just correct it on the spot and the vote can continue as-is.

If there are no issues, reply on the vote thread to close the voting. Then, tally the votes in a separate email. Here’s an email template; please adjust as you see fit.

From: Release Manager
To: dev@flink.apache.org
Subject: [RESULT] [VOTE] Release 1.2.3, release candidate #3

I'm happy to announce that we have unanimously approved this release.

There are XXX approving votes, XXX of which are binding:
* approver 1
* approver 2
* approver 3
* approver 4

There are no disapproving votes.

Thanks everyone!

Checklist to proceed to the finalization step

1. Community votes to release the proposed candidate, with at least three approving PMC votes

Fix any issues

Any issues identified during the community review and vote should be fixed in this step.

Code changes should be proposed as standard pull requests to the master branch and reviewed using the normal contributing process. Then, relevant changes should be cherry-picked into the release branch. The cherry-pick commits should then be proposed as the pull requests against the release branch, again reviewed and merged using the normal contributing process.

Once all issues have been resolved, you should go back and build a new release candidate with these changes.

Checklist to proceed to the next step

1. Issues identified during vote have been resolved, with fixes committed to the release branch.

Finalize the release

Once the release candidate has been reviewed and approved by the community, the release should be finalized. This involves the final deployment of the release candidate to the release repositories, merging of the website changes, etc.

Deploy artifacts to Maven Central Repository

Use the Apache Nexus repository to release the staged binary artifacts to the Maven Central repository. In the Staging Repositories section, find the relevant release candidate orgapacheflink-XXX entry and click Release. Drop all other release candidates that are not being released.

Deploy source release to dist.apache.org

Copy the source release from the dev repository to the release repository at dist.apache.org using Subversion.

Git tag

Create a new Git tag for the released version by copying the tag for the final release candidate, as follows:

git tag -s “release-${VERSION}” ${TAG}

Merge website pull request

Merge the website pull request to list the release.

Mark the version as released in JIRA

In JIRA, inside version management, hover over the current release and a settings menu will appear. Click Release, and select today’s date.

Checklist to proceed to the next step

• Maven artifacts released and indexed in the Maven Central Repository
• Source distribution available in the release repository of dist.apache.org
• Source distribution removed from the dev repository of dist.apache.org
• Website pull request to list the release merged
• Release tagged in the source code repository
• Release version finalized in JIRA. (Note: Not all committers have administrator access to JIRA. If you end up getting permissions errors ask on the mailing list for assistance.)

Promote the release

Once the release has been finalized, the last step of the process is to promote the release within the project and beyond.

Apache mailing lists

Announce on the dev@ mailing list that the release has been finished.

Announce on the release on the user@ mailing list, listing major improvements and contributions.

Announce the release on the announce@apache.org mailing list.

Recordkeeping

Use reporter.apache.org to seed the information about the release into future project reports.

Flink blog

Major or otherwise important releases should have a blog post. Write one if needed for this particular release. Minor releases that don’t introduce new major functionality don’t necessarily need to be blogged.

Social media

Tweet, post on Facebook, LinkedIn, and other platforms. Ask other contributors to do the same.

Checklist to declare the process completed

1. Release announced on the user@ mailing list.
2. Blog post published, if applicable.
3. Release recorded in reporter.apache.org.
4. Release announced on social media.
5. Completion declared on the dev@ mailing list.

Improve the process

It is important that we improve the release processes over time. Once you’ve finished the release, please take a step back and look what areas of this process and be improved. Perhaps some part of the process can be simplified. Perhaps parts of this guide can be clarified.

If we have specific ideas, please start a discussion on the dev@ mailing list and/or propose a pull request to update this guide. Thanks!