Workflow:Apache Airflow Core Release Process
| Knowledge Sources | |
|---|---|
| Domains | Release_Engineering, Open_Source, Software_Engineering |
| Last Updated | 2026-02-08 19:00 GMT |
Overview
End-to-end process for preparing, validating, and publishing an official Apache Airflow core release following the Apache Software Foundation release guidelines.
Description
This workflow documents the complete release management process for Apache Airflow core packages. It covers security review, cherry-pick selection for patch releases, i18n coordination, release candidate preparation (build, sign, publish), PMC verification (reproducibility, licensing, signatures), community voting, and final publication to SVN, PyPI, Docker Hub, and documentation sites. The process follows strict ASF governance with cryptographic signing, community voting, and reproducible builds.
Usage
Execute this workflow when you are the designated release manager for an Apache Airflow release (major, minor, or patch). This is relevant for PMC members and committers who have been assigned release management duties. The process differs slightly between major/minor releases (cutting from main) and patch releases (cherry-picking into stable branches).
Execution Steps
Step 1: Security Review and Release Planning
Review all security issues marked for the release in the security tracking repository. Verify that dependabot alerts and code scanning alerts have been addressed. For patch releases, identify candidate commits for cherry-picking from main into the stable branch. For major/minor releases, determine the branch cut point from main. Coordinate i18n translation completeness for UI strings.
Key considerations:
- Security issues must be resolved before the release candidate is prepared
- Patch releases cherry-pick specific bug fixes; major/minor releases include everything in main
- The i18n workflow requires checking translation completeness across all supported locales
- Milestone assignment tracks which PRs are included in the release
Step 2: Branch Preparation and Cherry-Picking
For patch releases, cherry-pick approved commits from main into the v{X}-{Y}-stable branch. Resolve any merge conflicts. For major/minor releases, create the v{X}-{Y}-test and v{X}-{Y}-stable branches from main. Collapse Cadwyn API version migrations if applicable. Review all cherry-picked PRs and assign appropriate labels.
Key considerations:
- Cherry-picking uses the .cherry_picker.toml configuration for automation
- The assign_cherry_picked_prs_with_milestone.py script helps track cherry-pick status
- Merge conflicts during cherry-picking require manual resolution
- Only bug fixes and documentation changes should be cherry-picked for patch releases
Step 3: Release Candidate Build and Signing
Build the release candidate artifacts: source distribution (sdist), wheel, and documentation. Sign all artifacts using GPG. Upload the signed artifacts to the Apache SVN staging area. Prepare the production Docker image release candidate. The build system uses hatchling with a custom hatch_build.py that compiles UI assets and generates version metadata.
Key considerations:
- The hatch_build.py plugin compiles UI assets and generates git version information during build
- The reproducible_build.yaml file enables deterministic builds for verification
- All artifacts must be cryptographically signed by the release manager
- The Towncrier tool generates release notes from newsfragments
Step 4: Release Candidate Verification
PMC members verify the release candidate through multiple checks: reproducible build verification, SVN artifact integrity check, license compliance verification, GPG signature validation, and SHA512 checksum verification. Contributors install the release candidate in local environments and test functionality. Automated verification can be performed using the Breeze tool.
Key considerations:
- Reproducible builds ensure the same source produces identical artifacts
- License checks verify all included files have proper Apache license headers
- Signature checks verify the release manager's GPG key
- The voting period follows ASF governance rules (minimum 72 hours)
Step 5: Community Voting and Approval
Conduct the formal Apache voting process on the dev@airflow.apache.org mailing list. Prepare the vote email with artifact locations, verification instructions, and changelog summary. Both PMC member and committer +1 votes are considered binding. The vote requires at least 3 binding +1 votes and more +1 than -1 votes. If the vote fails, address issues and prepare a new release candidate.
Key considerations:
- The vote email must include links to all artifacts, signatures, and checksums
- A minimum 72-hour voting window is required by ASF policy
- Failed votes require preparing a new RC with incremented RC number
- Vote results are summarized and published to the mailing list
Step 6: Final Release Publication
Upon successful vote, publish the release: move artifacts from SVN staging to release, publish to PyPI, build and push the production Docker image, publish final documentation, and clean up old release artifacts. The Docker image retagging tool handles multi-architecture image publication.
Key considerations:
- SVN publication uses the sign.sh script for artifact management
- Docker images are published to Docker Hub as apache/airflow
- Documentation is published to the airflow.apache.org docs site
- The retag_docker_images.py handles Docker image retagging across registries
Step 7: Post-Release Activities
Complete all post-release tasks: notify the developer mailing list, send security advisories for any fixed CVEs, update the Apache Committee Report Helper, create a GitHub release, close the milestone, announce on community Slack, post to social media, update main branch with latest release details, and update the Helm chart default Airflow version.
Key considerations:
- The send_email.py utility handles release notification emails
- GitHub releases are created with auto-generated release notes
- The Helm chart Chart.yaml must be updated with the new default Airflow version
- API client packages may need updates after a new release
- The release calendar (verify_release_calendar.py) tracks release dates and support timelines