The State of Software End-of-Life 2026

1. The projects hardest to plan around are the least likely to tell you when support ends. Among products that ship a new version less often than every three months, 43.4% of currently supported versions carry no published end-of-life date. Among fast-moving projects it is only 18.2%.
2. 416 release cycles reach end of life in the next twelve months, spread across 183 products, which is 43% of everything still actively developed.
3. The median version is supported for 18.5 months, and 33.1% of products support a version for under a year.
4. Support windows are not collapsing. Despite the common claim that the release treadmill keeps speeding up, 51.6% of products with enough history show no meaningful change in how long they support a version.

You would expect a project that ships a new version every few years to be clearest about when the old one stops being supported, because that is the one where planning actually matters. The data shows the opposite.

Splitting products by how often they release, and looking only at versions that are currently supported, 43.4% of versions from slower-releasing projects have no end-of-life date published at all. For fast-moving projects the figure is 18.2%. That inversion matters because a missing date on a fast-moving project is largely harmless, since the version will be superseded within weeks either way. A missing date on a project you will run for three years is a planning gap you cannot close.

163 slower-releasing products have no published end-of-life date on a single supported version. The list is not obscure software. It includes Apache Kafka, Apache Cassandra, Apache Airflow, Apache Flink, Apache Hadoop, Apache Lucene, Apache Maven and Ansible.

This is the single most useful thing in this report. If you are planning an upgrade cycle, the absence of a date is itself the finding. It means nobody upstream has committed to supporting what you are running, and no amount of checking a table later will change that.

Across products still under active development, 416 release cycles reach end of life within the next year, affecting 183 distinct products, or 43% of them. The load is spread fairly evenly rather than concentrated in one quarter, which means there is no single deadline to plan around and no quiet period either.

Measured across 396 products with enough completed history to judge, the median support window is 18.5 months. That is shorter than most annual planning cycles, and it means a version adopted at the start of a project may well be unsupported before the project ships.

The distribution matters more than the median. 33.1% of products support a given version for under twelve months, while 12.9% support one for five years or more. There is no typical case to design a policy around, which is why a single company-wide upgrade cadence tends to fit badly.

It is widely repeated that software support windows keep shrinking. On this dataset that is not true, and the honest answer is that most projects have not changed.

Comparing the first half of each product's completed release history against the most recent half, across the 320 products with at least six completed cycles: 51.6% show no meaningful change, 28.1% have shortened, and 20.3% have actually lengthened. The median change across all of them is 0 months.

So the difficulty is not that support is disappearing. It is that support windows vary enormously between projects and are often unpublished, which makes them hard to track rather than hard to live with.

Median support windows differ by more than a factor of two across categories. Cloud services lead at 37.2 months and operating systems follow at 34.7, while server applications sit at 15.5 months.

Release cadence does not simply mirror this. Cloud services ship the fastest of any category, roughly every 4.6 months, while also supporting versions the longest, which means many supported versions overlap at once. Frameworks are the opposite: the slowest to ship at about 11 months, yet supported for well under half as long as an operating system.

64 of the products measured, or 16.2%, ship a new version more often than every three months. For these, a very short per-version support window is a property of the release model rather than a sign of abandonment.

Firefox is the clearest example. Its median per-version support window is under a month, which sounds alarming and means nothing of the sort: Firefox is continuously maintained, and each version is replaced by the next on a fixed schedule. Reading its support window as neglect would be a straightforward misreading of the data.

The inverse also holds. The longest support windows in the dataset belong to enterprise server software and long-term-support Linux distributions, led by Apache HTTP Server at 139.3 months.

The practical rule: a short window is only a problem when you did not know about it. Which brings the analysis back to the first finding, because an unpublished window is the one you cannot know about.

All figures come from endoflife.date's openly licensed dataset (MIT), snapshotted on July 29, 2026 from upstream data generated 2026-07-29. The numbers on this page are frozen at that snapshot so that anything cited here stays citable. Hardware and device products are excluded, as they are not software dependencies.

Medians are used throughout rather than averages, so a single unusual release does not distort a product's figure. Category figures are a median of each product's own median, so a project with 140 tracked cycles does not outweigh one with six. A product needs at least three completed cycles before a support window is reported, and at least six before a trend is, and changes smaller than three months are treated as no change. Where there is not enough data, the product is excluded rather than estimated.

Known limitations

• Support windows describe measured release history, not a vendor's stated policy. A distribution that mixes short interim releases with long-term-support releases will show a median well below its headline support promise. Both numbers are correct and they answer different questions.
• Some products carry upstream data artifacts. Google Chrome, for example, tracks every numbered version as end-of-life once superseded, so it appears to have no supported version despite obviously being maintained. Internet Explorer shows the reverse. Such cases are excluded from the "longest support" figures by checking whether a product's newest cycle is still supported, but they can still affect aggregate counts.
• An absent end-of-life date is recorded as absent, not inferred. That is the point of Finding 1, but it does mean the true support window for those versions is unknown rather than short.
• The dataset covers products tracked by endoflife.date. It is broad but not exhaustive, and coverage is better for widely used infrastructure than for niche tooling.