Discover more from hrbrmstr's Daily Drop
Drop #263 (2023-05-17): May `23 Quick Links Week Day #3 — Bring Out Your Dead
openplf; outdated*; monorepo tools
Relying on legacy dependencies is very, very bad. So, today we help you do that in a few different ways.
The Open Product Lifecycle Framework (OPLF) (GH) is an initiative aimed at standardizing the way End-of-Life (EOL) and End-of-Support (EOS) information is exchanged within the software and hardware industries. Covering both vendors and open-source maintainers, OPLF strives to provide a transparent, efficient, and unified approach to managing product lifecycles; and, provides a common framework that simplifies the process of managing and sharing EOL and EOS information across the industry.
This is a great overview of what/why, but in case you need a TL;DR for it:
Omar (the author) posits there is a need for standardized EoL/EoS programs across the software industry to reduce confusion and ensure a smooth transition for customers.
This standard brings benefits like improved communication, enhanced trust, increased stability for businesses, and support for open-source sustainability.
The standard can benefit FOSS projects, but not without some challenges.
Your org can gain benefits such as streamlined product management and strengthened customer trust (ed: I think this depends a heavy bit on org maturity, tho.)
You are responsible for defining key milestones in your own EoL/EoS program, and they should be clearly defined and communicated, like end of sales, end of support, and end of life.
Standardized timelines are essential. (ed: I'd argue this is a “non-negotiable” requirement)
Omar suggests you should have a centralized, documented way to ensure folks know how to grab this info.
You aren't limited to the proposed schema, but you should use it as a minimum standard and join with the folks who maintain it to help make it useful.
I guess my only question is: what happens if you’re using an outdated version of the standard?
This section def lives up to the “quick hits” title, and features three useful “check for outdated dependencies” projects in various languages.
outdated: this library works by fetching a URL such as “https://pypi.org/pypi/requests/json”. The time it takes to visit that link is essentially the speed of the library. This is much faster than the command
pip list --outdatedor any equivalent code.
cargo outdated (Rust deps freshness manager)
go mod outdated (Golang deps freshness manager)
JS folks have a rich ecosystem for this, and Snyk has a good Java 'splainer on the topic.
Not so much focused on dependency management-proper, monorepo.tools is a great resource if you're stuck in monorepo land (like me).
I'm including it, though, since it does have a most excellent section on dependency management strategies for these unwieldy beasts.
In other news: 🤞🏽 I make it back from the Beltway today. 🚙 ☮