Sources and methodology

Everything on this site is rebuilt every morning from public, official sources. When a source cannot be fetched, the previous copy is kept and its date below stays old. If a listed version is missing its release date, end-of-life date or latest patch, the build stops and the previous day's site stays up.

Sources

How statuses are computed

• Release date of a minor: the publish date (UTC) of its vX.Y.0 release on GitHub.
• End of life: from the release schedule (supported versions) or the end-of-life list (older ones). On or after that date a version is End of life.
• Maintenance mode: from the schedule's maintenanceModeStartDate; a version also shows Ending soon in its last 60 days. Otherwise Supported. For old versions without a published maintenance date, the timeline shades the final two months as an estimate (dashed).
• Latest patch: the highest vX.Y.Z tag published as a GitHub release.
• Removed APIs: an API kind is removed in the release given by its APILifecycleRemoved marker, or in the migration guide where the kind no longer exists in the source.
• Off by default: alpha versions always; beta versions introduced in 1.24 or later unless an older beta of the same kind was already on (KEP-3136, “beta APIs off by default”). This is derived from the data, not read from a flag.
• Replacement: the marker's replacement, followed until we reach a version that is still served (so flowcontrol.apiserver.k8s.io/v1beta1 points to v1, not to the also-removed v1beta2).
• The discovery document type apidiscovery.k8s.io is left out: nobody writes it in a manifest.

Validation, run on every build

1. Release dates: GitHub vs release schedule vs announcement

22 of 22 versions agree within one day across every source that has them.

2. Final patch of end-of-life versions: eol.yaml vs GitHub

17 of 18 match. Mismatches (the site shows the GitHub tag as “latest patch”):

• 1.29: the end-of-life list names 1.29.14 as the final patch; GitHub has 1.29.15 as a later release.

3. Support length vs policy

Policy: about 14 months (12 + 2 in maintenance) from 1.19 on, about 9 months before. 18 of 22 versions fall within ±1.6 months. Outside:

• 1.16: 11.5 months (policy ≈ 9).
• 1.17: 13.2 months (policy ≈ 9).
• 1.18: 14.8 months (policy ≈ 9).
• 1.22: 16.1 months (policy ≈ 14).

4. API removals: migration guide vs source markers

The guide lists 50 kind/version removals. 45 agree with the source markers, and 5 cannot be compared because the kind is no longer in the source:

• autoscaling/v2beta2 HorizontalPodAutoscaler, removed in 1.26 per the guide
• autoscaling/v2beta1 HorizontalPodAutoscaler, removed in 1.25 per the guide
• policy/v1beta1 PodSecurityPolicy, removed in 1.25 per the guide
• apps/v1beta1 ReplicaSet, removed in 1.16 per the guide
• extensions/v1beta1 PodSecurityPolicy, removed in 1.16 per the guide

Removals of on-by-default APIs that the markers record but the guide does not list (mostly sub-resources and webhook payload types, which the guide folds into their parent resources):

• admission.k8s.io/v1beta1 AdmissionReview, removed in 1.22
• apps/v1beta1 ControllerRevision, removed in 1.16
• apps/v1beta1 DeploymentRollback, removed in 1.16
• apps/v1beta1 Scale, removed in 1.16
• apps/v1beta2 ControllerRevision, removed in 1.16
• apps/v1beta2 Scale, removed in 1.16
• extensions/v1beta1 DeploymentRollback, removed in 1.16
• extensions/v1beta1 Scale, removed in 1.16
• policy/v1beta1 Eviction, removed in 1.25
• apiextensions.k8s.io/v1beta1 ConversionReview, removed in 1.22

The guide's newest section is 1.32. The markers record 8 later removals; by the rule above, 8 of them were alpha or off-by-default beta versions. The off-by-default rule is derived from introduction dates, not read from the API server; a beta kind added to an existing group can behave differently, so check a live cluster with kubectl api-resources.

5. Skew policy text

7 of 7 key sentences that the skew calculator encodes are still present, word for word, in the current policy page.

6. Managed services vs upstream

Each provider's end of standard support is compared with the upstream end of life (a sanity check that versions line up). Standard support ending more than 200 days before upstream would suggest a parsing error; 0 such cases.

What we do not claim

• Release highlights are short summaries; the release notes and changelogs are the reference for your components.
• Managed-service dates can move; providers call some of them estimates. We show what their pages say on the day checked.
• Vendor distributions (OpenShift, Rancher, Tanzu, k3s…) have their own support policies and are not covered.