Systems Software Data: Package Registries, Vulnerability Records and Fleet Telemetry · Head-to-head
endoflife.date Product Lifecycle Catalog vs npm Public Registry API
Which systems software data: package registries, vulnerability records and fleet telemetry data fits your job: endoflife.date Product Lifecycle Catalog, or npm Public Registry API. API, files, or your warehouse. Daily, weekly, or hourly.
endoflife.date Product Lifecycle Catalog
npm Public Registry API
Coverage, side by side
| endoflife.date Product Lifecycle Catalog | npm Public Registry API | |
|---|---|---|
| Geographic | None by design - a lifecycle date is a property of the product, not the customer's country; Windows leaves support everywhere on the same day | Global namespace with worldwide download aggregates; geography surfaces implicitly through maintainer names and repository links rather than as a partition |
| Temporal | Historical release dates paired with vendor-published windows reaching past 2036 (Ubuntu 26.04 extended security lands 2036-04-30); continuously updated, with automated commits observed landing multiple times during the August 2026 verification pass | Publication timestamps back to the registry's 2010 inception plus current registry state; download counts from 2015-01-10 through yesterday; nothing scheduled ahead |
What each contains
They tie on 1 attribute. Pick by fit, not by loyalty.
| endoflife.date Product Lifecycle Catalog | npm Public Registry API | |
|---|---|---|
| Publisher | endoflife.date, the community-maintained lifecycle tracker aggregating vendor-published dates and linking every product to its upstream release policy | npm, operator of the authoritative registry for the JavaScript and Node.js package ecosystem |
| Subject lens | Retirement view of software: when each release cycle stops receiving features, patches and extended security - operating systems, databases, languages, frameworks, devices, services and standards such as PCI-DSS and TLS | Ecosystem view of one language: what was published, who maintains it, what it depends on and how much it is downloaded, per package and per version |
| Geographic coverage | None by design - a lifecycle date is a property of the product, not the customer's country; Windows leaves support everywhere on the same day | Global namespace with worldwide download aggregates; geography surfaces implicitly through maintainer names and repository links rather than as a partition |
| Temporal coverage | Historical release dates paired with vendor-published windows reaching past 2036 (Ubuntu 26.04 extended security lands 2036-04-30); continuously updated, with automated commits observed landing multiple times during the August 2026 verification pass | Publication timestamps back to the registry's 2010 inception plus current registry state; download counts from 2015-01-10 through yesterday; nothing scheduled ahead |
| Detail level | One record per product per release cycle - typically 3 to 30 cycles per product, thousands of release records overall | Per package, per version and per maintainer in metadata; per package per day in download counts (per-version breakdowns limited to the trailing seven days) |
| Documented fields | 17 verified definitions spanning the product spine and the per-cycle date ladder | 28 verified definitions spanning the metadata, download-count and search surfaces |
| Scale | 464 products; a few thousand release-cycle records small enough to load whole | Roughly 4.3 million package documents, of which about 2.5 to 3 million carry any download record |
| Best for | Upgrade-roadmap planning, patch and exposure scoping, compliance mapping, vendor-risk scoring, asset-management automation | — |
Where they're equivalent
More than their opposite temperaments suggest.
- Both are first-party community infrastructure - one a volunteer-maintained tracker aggregating vendor-published dates, the other the registry operators' own authoritative store, so provenance is close to the fact on each side.
- Both carry fully verified field dictionaries - 17 and 28 definitions checked against live values during the August 2026 pass, a standard met by roughly 86 percent of the 1,744 cataloged datasets.
- Both score 10 out of 10, tied at the very top of the rubric - and of this slice's 17 records, seven reach that mark.
- Both are current at a cadence most catalogs never hit: automated lifecycle commits were observed landing multiple times daily during verification, while registry publishes appear essentially live.
- Neither substitutes for the other: the catalog has no usage column, the registry no scheduled-support column. A dependency review that checks a library is maintained and checks it is actually installed ends up wanting both.
Or take both in one feed
Yes - as two clocks on one dependency decision rather than one table.
Join discipline matters more than usual, because there is no native key between a product catalog and a package registry. Treat the catalog's zeros carefully too: a missing row means nobody tracks the product yet, not that it is retired.
Datadory ships either record alone or both resolved onto one key, normalized to their documented dictionaries before anything leaves the door - request a sample and it arrives pre-cut to your named products, packages and windows, with field definitions and coverage profiles attached. Or rank the whole pool on the best systems-software datasets page. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Do the two field dictionaries overlap?
In skeleton only. Both name their subject, classify it and stamp time on every row. No column name survives translation between them.
Which dataset reaches further forward in time?
The lifecycle catalog by years: its rows are scheduled futures, including Ubuntu 26.04 extended security on 2036-04-30 and Windows 11 26H1 Enterprise ending active support and life together on 2029-03-13.
Which dataset shows whether a package is actually used?
The lifecycle catalog carries no usage measure at all; being tracked there means only that a vendor still publishes dates for a product.
Which dataset covers more ground?
Different senses of more. The registry holds roughly 4.3 million package documents - but all within one language ecosystem. The catalog holds just 464 products - spread across operating systems, databases, languages, frameworks, devices, services and standards such as PCI-DSS, covering platforms far beyond any single runtime's reach.
Can Datadory deliver both datasets together?
Yes - sample both, then take them separately or joined on product and version names, delivered daily, weekly, or hourly - your call. Each arrives normalized to its documented dictionary (17 fields for the catalog, 28 for the registry) with sample rows attached for validation, alongside the rest of the Systems Software shelf.