hrbrmstr's Daily Drop

Share this post

Drop #263 (2023-05-17): May `23 Quick Links Week Day #3 — Bring Out Your Dead

dailyfinds.hrbrmstr.dev

Drop #263 (2023-05-17): May `23 Quick Links Week Day #3 — Bring Out Your Dead

openplf; outdated*; monorepo tools

boB Rudis
May 17, 2023
Share
Share this post

Drop #263 (2023-05-17): May `23 Quick Links Week Day #3 — Bring Out Your Dead

dailyfinds.hrbrmstr.dev

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

green grass field with trees and a black and white cross
Photo by Viktor Forgacs on Unsplash

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. 🚙 ☮

Share
Share this post

Drop #263 (2023-05-17): May `23 Quick Links Week Day #3 — Bring Out Your Dead

dailyfinds.hrbrmstr.dev
Previous
Next
Comments
Top
New
Community

No posts

Ready for more?

© 2023 boB Rudis
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing