Apache HTTP Server Support Lifecycle & Release History

Apache HTTP Server Odd-Even Branch Strategy and GA Release Windows

Apache HTTP Server follows an odd-even minor version strategy: odd-numbered minor releases (2.1, 2.3, 2.5) are development branches, while even-numbered minor releases (2.2, 2.4, 2.6) are General Availability (GA) stable branches intended for production use. Only GA branches receive active maintenance and security patches.

Each development branch progresses through alpha and beta phases before stabilizing into its corresponding GA release. For example, the 2.5 development tree in trunk is slated to graduate as the 2.6 GA branch. This means operators should only track even-numbered minor versions when planning production deployments.

Apache does not publish a fixed support duration window or a rolling LTS program. A GA branch remains supported as long as the project actively maintains it -- as shown in the release table above, this can span well over a decade. A branch reaches End of Life when the project ceases issuing security advisories and patch releases for it.

The patch version (the third number, e.g. 2.4.67) increments with each bugfix or security release within a GA branch. Apache does not retire patch releases -- the latest patch within the current stable branch is always the recommended version.

For official release policy details, see the Apache HTTP Server Release Guidelines.

Unpatched CVEs and Module Compatibility Decay on EOL httpd Branches

Running an EOL Apache httpd branch means accepting a growing backlog of unpatched CVEs, with no official fix path from the project. Apache's security team publishes advisories against the current stable branch only -- vulnerabilities disclosed after a branch's EOL date will never receive an official patch for that branch.

Apache httpd's module ecosystem (both bundled modules like mod_ssl, mod_proxy, and third-party DSOs) evolves alongside the active branch. Modules built against or dependent on APIs from an EOL branch may silently misbehave as upstream libraries (OpenSSL, APR, PCRE) release breaking changes. The Apache Portable Runtime (APR) and APR-util libraries that httpd depends on follow their own release cycle, and EOL httpd versions may fall out of compatibility with current APR releases.

TLS configuration is a concrete area of decay. An EOL httpd branch may lack support for current cipher suites, TLS 1.3 handshake behaviors, or certificate validation improvements introduced in newer OpenSSL versions. In practice, this creates a compound exposure: the web server itself is unpatched, and its TLS stack may silently negotiate weaker parameters than intended.

Reverse proxy and load balancing configurations (mod_proxy_balancer, mod_proxy_http2) are also affected -- backend protocol assumptions baked into older branches may diverge from current backend server expectations, producing subtle interoperability failures rather than hard errors.

Feature Freeze and Patch Cessation: What EOL Means for an httpd Branch

When an Apache httpd branch reaches End of Life, the project stops issuing security advisories, patch releases, and CVE fixes for that branch. There is no grace period, no commercial extended support from Apache itself, and no backporting of fixes from the current stable branch.

The source code remains available in the Apache SVN repository and GitHub mirror, but it is frozen in time. No commits flow into the EOL branch. If a new vulnerability is disclosed that affects both the EOL branch and the current stable branch, only the current stable branch receives the official fix.

For migration, the upgrade path is to the current stable GA branch -- as shown in the release table above. Because Apache httpd maintains module API compatibility within a GA branch (e.g., modules compatible with 2.4.1 remain compatible with later 2.4.x releases), the main migration effort involves reviewing configuration syntax changes and deprecated directives between major branches. The official Upgrading to 2.4 from 2.2 guide documents the breaking directive changes between branches.

Some Linux distributions (RHEL, Ubuntu LTS) ship patched builds of older httpd branches with vendor-backported security fixes beyond the upstream EOL date. This is distribution-specific extended support, not Apache project support -- the vendor's patch set, not the upstream branch, defines what is actually fixed.

CLI and Server-Status Methods for Identifying Your Running httpd Version

The fastest way to check the Apache HTTP Server version is via the command line using the httpd or apache2 binary with the -v flag.

Standard version check

httpd -v
# or on Debian/Ubuntu-based systems:
apache2 -v

This outputs the server version and the build date. To also see compiled-in modules and build flags:

httpd -V
# or:
apache2 -V

Check version on a running server via mod_status

If mod_status is enabled, the server version appears in the Server header and in the status page:

curl -I http://localhost/
# Look for: Server: Apache/2.4.x (platform)

Check via package manager (Linux)

# RHEL / CentOS / Fedora
rpm -q httpd

# Debian / Ubuntu
dpkg -l apache2

Note that the package manager version reflects the distribution's packaged version, which may differ from upstream due to vendor backports. The binary -v flag reflects the actual compiled version string.

Windows (XAMPP / manual installs)

httpd.exe -v