It is NOT necessary to run all checks to cast a vote for a release candidate.
However, you should clearly state which checks you did when casting a vote.
The release manager needs to ensure that each following check was done.

Legal Verifications

Checking Artifacts

Some of these are strictly required for a release to be ASF compliant.

  • (required) Verify that the checksums and GPG files match the corresponding release files, for:
  • (required) Verify that the source distributions do not contain any binaries
  • (required) Build the source distribution to ensure all source files have Apache headers
    • Run "mvn clean install -DskipTests" in the maven source distribution.
  • (required) Verify that all POM files point to the same version.
  • Check that the README.md file does not have anything unexpected.

Checking Licenses

These checks are strictly required for a release to be ASF compliant.

Important: These checks must be performed for

  • the Source Release
  • the Helm Release
  • the artifacts (jar files uploaded to Maven Central)

Checks to be made include

  • All artifacts should contain an Apache License file and a NOTICE file as described below
    • For Maven artifacts that DO NOT bundle any external dependency, the NOTICE file is pulled in automatically via the apache-jar-resource-bundle defined in the Apache parent pom. There is no need to manually checkin the NOTICE and LICENSE files into the repo.
    • For Maven artifacts that DO bundle (usually through the maven-shade-plugin) any external dependency, the NOTICE file must be included in the src/main/resources/META-INF directory of the respective module.
    • Use "jar tf <jar file>" to check if the Maven artifacts contain any external dependency.
  • Non-Apache licenses of bundled dependencies must be included in the src/main/resources/META-INF/licenses/ directory of the respective module.
  • The NOTICE files should include all copyright notices and all bundled dependencies.

A detailed explanation on the steps above is in Licensing.

Testing Functionality

This is not necessarily required for a release to be ASF compliant, but required to ensure a high quality release.

This is not an exhaustive list - it is mainly a suggestion where to start testing.

Validate Helm Chart and Docker image

Validate the helm chart included in the repo:

  • Verify that chart and appVersion matches the target release
  • Verify that helm chart / values.yaml points to the RC docker image ( ghcr.io/apache/flink-operator:{release-commit-hash}) 
  • Verify Helm chart can be installed without overriding any parameters (except for turning of the webhook if necessary)
  • Verify that RC repo works as Helm repo (helm repo add operator-rcX https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-1.2.3-rcX) 

Validate the docker build

  • Build the docker container locally and test it

Operator functionality manual testing

For some of the included examples:

  • Submit yaml
  • Submit job / spec upgrade
  • Validate operator logs
  • Validate deployment status

For stateful examples

  • Verify stateful upgrade uses the correct checkpoint/savepoint
  • Trigger manual savepoint

Test multiple Flink versions if possible

  • Try testing new, or upcoming Flink versions
  • Try testing some old Flink versions

Built-in tests

Check if the source release is building properly with Maven, including checkstyle and all tests

  • Command: mvn clean verify

  • Build for Java 11

  • No labels