

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.
openplf
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?
outdated*
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 --outdated
or 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.
monorepo tools
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.
FIN
🚨 Mind your VS Code extensions!
In other news: 🤞🏽 I make it back from the Beltway today. 🚙 ☮