endoflife.date

This is helpful, but it is yet to be seen how downstream picks it up. Wikidata[0] has renamed it and marked the Vinyl repo as the preferred one. Gentoo[1] renamed the package and switched to Vinyl. Homebrew[2] is now tracking Varnish Software (downstream of Vinyl). Fedora[3] has switched to Varnish Software as well. At endoflife.date[5], we renamed to vinyl and switched tracking as well. Wikipedia[6] has renamed Varnish (Software) -> Vinyl Cache. [0]: https://www.wikidata.org/wiki/Q1602447 [1]: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=679937b... [2]: https://github.com/Homebrew/homebrew-core/pull/273280 [3]: https://src.fedoraproject.org/rpms/varnish/c/59f403810b746e0... [4]: https://repology.org/project/varnish/packages [5]: https://github.com/endoflife-date/endoflife.date/pull/9792 [6]: https://en.wikipedia.org/wiki/Vinyl_Ca

We use at endoflife.date, and are fairly happy. We had to add a workaround to get some search terms working (because of how it does stemming, searching for BSD wouldn't show openbsd earlier): https://github.com/endoflife-date/endoflife.date/issues/4924), but it is still not 100% perfect: searching for fusion still doesn't get you coldfusion.

Thanks a lot, I've added Metaport to our list of known users: https://github.com/endoflife-date/endoflife.date/wiki/Known-...

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors[0] or Open Collective[1]. But even better would be to file a small PR against our open requests[2] or the open requests for very-helpful-products[3]. We have a nice guide that covers contributing new products https://endoflife.date/contribute Some updates since the last time [-1] we were on HN (Dec 2023). - We recently launched our v1 API[4] (Big thanks to Marc for pushing this). - We have a (non-exhaustive) list of companies and products that use the API and dataset in interesting ways[5]. Just reply to get something added. - We are looking at documenting our Breaking Changes better for notifying users. feedback is welcome[6] [-1]: https://news.ycombinator.com/item?id=

Really appreciate you building and maintaining it these years! endoflife.date has been an amazing resource ever since you put it up. This has been a great open source success story that I share with people to explain why open source can be great. It's also a great example of the power of crowd-sourcing data. I originally added Ruby[1], Fedora[2], and Alma Linux[3] to endoflife.date and it's rewarded me with years of ability to reference. Prior to this I kept my own notes for the projects I cared most about, but keeping those up to date was a PITA. The best ideas seem obvious in hindsight, and endoflife.date definitely seems obvious :-D [1] https://github.com/endoflife-date/endoflife.date/commit/7dae... [2] https://github.com/endoflife-date/endoflife.date/commit/ab16... [3] https://github.com/endoflife-date/endoflife.date/commit/1

Request for the bun team: please provide a clear support policy/EOL timeline. Bonus points for clarity on the stability guarantees that are offered between versions and modules. https://github.com/oven-sh/bun/issues/7990 (Via https://github.com/endoflife-date/endoflife.date/pull/4382)

Yes, we have an open issue for such timelines (https://github.com/endoflife-date/endoflife.date/issues/2148). Your comment has given me the idea to implement it on our "tag" pages, so you could see the timeline for all java-runtimes in one place for eg. Generating pages isn't hard for us. We maintain it in our frontmatter/yaml (See https://github.com/endoflife-date/endoflife.date/blob/master... for example). The release-data repo is for tracking new releases of upstream products so we can patch the latest version automatically, and get notified of new major releases that are missing in our tables. release-data is a much smaller subset of our data, and doesn't include the critical EOL data.

> where you can see overlapped timelines when support ended I tried to generate a visual timeline for a given page (https://github.com/endoflife-date/endoflife.date/pull/2859, has some screenshots), but it was limited to a single page (so you'd only see nokia devices at once for eg). It turned out that it is too hard to generate clear charts with vague data. We often only know whether is device is supported or not (true/false, see comments about samsung below in this thread), and don't have clear release dates. I'll get to it someday (PRs welcome), but it might not work for the usecase we want (picking phones) because data on mobiles is very vague. repairability score -> sounds interesting, will file an issue and see. The hard part is that there's no clear identifiers for devices (SWID/CPE are just not good enough) for us to track this ki

Thank you for creating this. We keep track of EOL dates in our internal wiki with links to various websites. Would be nice to reduce the scatter and just link to this site! Would you accept Pull Requests that add server hardware EOS and EOL dates? They are especially hard to find and it would be great to have them in there as well! Edit: I should have taken a look at open issues first, it seems there is tracking issue for network equipment so I guess adding server hardware is certainly not off the table (https://github.com/endoflife-date/endoflife.date/issues/1387).

We have an open issue for a timeline view: https://github.com/endoflife-date/endoflife.date/issues/2148 Second is very subjective. If there's onething that I've learnt over the years working on this - it is that the definition of "support" is very fuzzy. You can't even compare what "LTS" means between different stacks/products, so it is hard to objectively rate anything. It still might be worth doing some analysis and publishing as a blog post though, but i'm not sure if it can be automatically calculated.

1. We already have a calendar feed that you can subscribe to, for every product that will warn you accordingly. 2. We have an API (endoflife.date/api) and a upcoming v1 API (https://github.com/endoflife-date/endoflife.date/pull/2080) to let everyone use our data. 3. there's already a ton of companies/products that use the api/dataset (https://github.com/endoflife-date/endoflife.date/wiki/Known-...) We plan to launch some services (https://github.com/endoflife-date/endoflife.date/issues/2108), but it will still be free. We treat it as a community-built-semantic-wiki. Feedback is welcome.

Currently none, but that's mostly because we've worked hard to keep it that way. I publish finance updates on a GitHub Discussion (https://github.com/endoflife-date/endoflife.date/discussions...). We used to pay $9/mo for Netlify Analytics but didn't find it helpful. We're looking to join OpenEoX.org to standardize EoL information publication, but that requires a lot more funds (https://github.com/endoflife-date/endoflife.date/discussions...). We also have a pretty long roadmap (https://github.com/endoflife-date/endoflife.date/issues/2108) that focuses on integrating better with the sbom ecosystem (We want to make an API that does SBOM->EOL alerts for eg). Such projects require a lot of development effort, and we'd like to be able to sponsor it on our own (via grants/donations).

Yes. we sometimes track such times using web archive, but it's not perfect and its easier to just use yes/no (See https://github.com/endoflife-date/endoflife.date/pull/4235 for eg).

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors or https://opencollective.com/endoflife-date We recently crossed 8M impressions via Google Search this month: https://github.com/endoflife-date/endoflife.date/discussions...

I've filed a PR[0] for endoflife.date/ubuntu, (Preview[1]). Would appreciate feedback if this helps understand the mess. [0]: https://github.com/endoflife-date/endoflife.date/pull/2424 [1]: https://deploy-preview-2424--endoflife-date.netlify.app/ubun...