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:
- All artifacts to be released to Maven in the staging Apache Nexus Repository
- Java source distributions staged in https://dist.apache.org/repos/dist/dev/flink
- (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