Releases and Versioning#

Falcon is developed in the open (yes, You can contribute too!) primarily using the falconry/falcon GitHub repository. Newer releases are available from our GitHub release page. Unless noted otherwise in specific files, Falcon releases are covered by the Apache 2.0 License.

Semantic Versioning#

Falcon strictly adheres to SemVer – incompatible API changes are only introduced in conjunction with a major version increment. Furthermore, when we make breaking changes in a new major version of the framework, the old behavior or feature removal is deprecated in advance at least one minor release leading to the change. In addition to documenting deprecations, we do our best to emit deprecation warnings (where feasible).

While there seems to be no clear consensus on whether removing platform support constitutes a SemVer breaking change, Falcon assumes that it does (unless we have communicated otherwise in advance, e.g., the Falcon 4.x series only guarantees Python 3.10+ support).

Supported Releases#

Current Release

As Falcon is a relatively small project with limited resources and funding, we only actively support the current SemVer major/minor release.

Although older minor releases from the current Falcon series are formally considered EOL, the upgrade path to the current release ought to be effortless thanks to Falcon’s strict SemVer guarantees.

Security Maintenance

We also provide limited security maintenance for the latest release of the old stable SemVer major series until (1) it falls back two major releases behind, or (2) 730 days (two years bar the possibility of a leap year) pass from the first release of the current stable series (whichever comes first).

“Security maintenance” of an old stable release here means providing new patch versions in response to security vulnerabilities. Other bugs (regardless of their impact) and compatibility with new Python versions are only addressed in the Current Release. Reported security vulnerabilities are evaluated on a case by case basis, with the Common Vulnerability Scoring System (CVSS) score reaching at least “Medium” (4.0+) as a starting point.

EOL

Other Falcon versions are considered End of Life (EOL).

If you are stuck on an old Falcon version, you are still welcome to ask for help! However, while we may be able to advise how to work around a specific issue, we will not ship new patch versions to EOL Falcon releases.

Stable Release Status#

The below table summarizes the history of Falcon stable (1.0+) releases alongside their maintenance status:

Major/Minor Version

First Release

Latest Patch Release

Release Status

4.2

4.2.0 (2025-11-10)

4.2.0

Current Release

4.1

4.1.0 (2025-08-06)

4.1.0

EOL

4.0

4.0.0 (2024-10-18)

4.0.2 (2024-11-06)

EOL

3.1

3.1.0 (2022-03-25)

3.1.3 (2023-12-05)

Security Maintenance

(until 2026-10-18)

3.0

3.0.0 (2021-04-05)

3.0.1 (2021-05-11)

EOL

2.0

2.0.0 (2019-04-26)

2.0.0

EOL

1.4

1.4.0 (2018-01-16)

1.4.1 (2018-01-16)

EOL

1.3

1.3.0 (2017-09-06)

1.3.0

EOL

1.2

1.2.0 (2017-05-02)

1.2.0

EOL

1.1

1.1.0 (2016-10-27)

1.1.0

EOL

1.0

1.0.0 (2016-05-11)

1.0.0

EOL

(You can find even older (0.x) release history in our repository’s commit tree, or PyPI.)

Pre-releases and Development Versions#

The upcoming Falcon version release normally lives in our main development branch (master). If you absolutely need a new unreleased feature or fix, You can install it directly from GitHub, however, we strongly recommend to deploy only stable Falcon releases to production. That being said, we do try to keep the main development branch in good shape at all times; our Continuous Integration gates ensure that both master commits, and pull requests being merged, pass all tests on the supported platforms.

Prior to a new stable release, we normally cut several alphas, betas, and release candidates. Falcon has no fixed pre-release schedule (unlike, e.g., CPython), and the exact number of pre-releases depends on many factors, such as the scope of the impending stable release, the extent of issues found in beta testing, and ultimately, it is decided at the discretion of the release manager and the core maintainer team.