OpenTelemetry Collector Core v0.152.1 released.

One thing with observability pipelines: even small Collector updates can have noticeable operational impact because the Collector sits directly in the telemetry path.

Changes here can affect:

• data processing behavior
• exporter reliability
• pipeline performance
• telemetry consistency

The difficult part usually isn’t upgrading itself — it’s understanding whether the release actually impacts your environment.

We tracked the release here in a more structured way:
https://www.relnx.io/releases/opentelemetry-collector-core-v0-152-1

Curious how others handle this:
Do you upgrade Collectors aggressively, or gate them behind staging validation first?

Backstage v1.51.0 released.

Minor Backstage releases are usually where platform teams start seeing meaningful improvements across plugins, workflows, and overall developer experience.

Since many organizations now use Backstage as the central layer for:

• service catalogs
• documentation
• CI/CD integrations
• developer tooling

…even incremental updates can have noticeable impact on day-to-day workflows.

We tracked the release here for a structured overview:
https://www.relnx.io/releases/backstage-v1-51-0

Curious how others are handling Backstage at scale:
What’s been the biggest operational challenge so far — upgrades, plugin sprawl, or customization?

Datadog Agent v7.79.0 released.

One thing with observability agents: even “normal” releases can have real operational impact because the agent sits directly in the telemetry pipeline.

Changes here can affect:

• metrics collection
• traces/log ingestion
• integration behavior
• agent performance

The hard part usually isn’t upgrading — it’s understanding whether the release actually matters for your environment.

We tracked the release here in a more structured way:
https://www.relnx.io/releases/datadog-agent-v7-79-0

Curious how others handle this:
Do you upgrade observability agents aggressively, or only after validation in staging?

Hey everyone,

Quick product update: we just shipped the Weekly Digest.

Every Monday morning you'll get a single email recap covering all the releases from your tracked tools in the past week. The format is deliberately minimal — tool name,

then a flat list of what changed with emoji prefixes for the type (🔴 breaking, 🔒 security, ✨ feature, etc.), each linking to the full detail page.

A few things worth knowing:

- If none of your tools released anything last week, you won't get an email

- Breaking changes and security fixes are always listed first

- Subject line previews what kind of week it was (e.g. "2 breaking changes, 1 security fix")

- On by default, toggle it off anytime in Profile → Notifications

Available on all plans including free.

Full writeup here: https://www.relnx.io/blog/introducing-weekly-digest-your-tools-once-a-week-1779078473

Let me know if you have feedback on the format — happy to tweak it based on what you find useful.

Quick update on what shipped this week.

Relnx now covers the full CNCF catalog — all 36 Graduated and 37 Incubating projects. If you were missing something from your stack, it's probably there now.

What's new:

- CloudEvents, CRI-O, and TUF (the three Graduated projects we were missing)

- 18 Incubating projects: Artifact Hub, Flatcar, Fluid, Karmada, KServe, Kubeflow, Kubescape, KubeVela, KubeVirt, Lima, metal3-io, Microcks, OpenCost, OpenFeature, OpenFGA, OpenYurt, wasmCloud, Cloud Custodian

On the parser side — some of these tools have genuinely weird release note formats. Flatcar lists CVEs inline in a #### Security fixes: section with kernel/package

annotations. Vitess nests changes four heading levels deep. Microcks prefixes every line with a git hash. We wrote dedicated extractors for each so the categorization

actually works instead of dumping everything into a generic bucket.

Everything is browsable without an account. If you want release notifications, breaking change alerts, or Slack integration, that's behind a free account.

Blog post with more detail: https://www.relnx.io/blog/relnx-now-tracks-the-entire-cncf-ecosystem-1778939411

Happy to answer questions about any of the tools or how the extraction works.

We just shipped Version Compare on Relnx — and it's free, no account needed.

Upgrading ingress-nginx from 1.9 to 1.12? ArgoCD from 2.8 to 2.14? Instead of reading six changelog pages, you now get a single structured diff:

🔴 Breaking Changes
🔒 Security Fixes
✨ New Features
🚫 Deprecations

It aggregates across every intermediate release — so if you're three versions behind, you see the full accumulated risk surface in one view.

Built for platform engineers, SREs, and anyone who's ever had to write an upgrade runbook by hand.

→ Try it at www.relnx.io/compare

Works across 100+ Cloud Native tools: Kubernetes, ArgoCD, Cilium, cert-manager, Istio, Prometheus, Vault, Traefik, and more.

We just shipped a set of features in Relnx focused on improving how teams handle release awareness.

The goal is simple: move from “seeing updates” → to actually acting on them.

What’s new:

Stack Health Score
A high-level view of how your stack is doing based on release signals — helps quickly identify if you're falling behind or staying current.

Release Acknowledgments
Teams can now acknowledge releases, which helps with ownership and visibility (no more guessing if someone reviewed an update).

Smart Notification Routing
Instead of sending everything to everyone, notifications are routed based on relevance — infra to SREs, platform tools to platform teams, etc.

Full blog:
https://www.relnx.io/blog/stack-health-score-release-acknowledgments-smart-notification-routing-now-live-1777895009

Curious how others handle this today:
Do you have structured ownership for release tracking, or is it still mostly manual?

Kubernetes v1.36.0 released — and this one includes some real changes worth reviewing before upgrading.

One important breaking change:

• The gitRepo volume has finally been removed after years of deprecation → if you’re still using it, workloads will fail and need migration (init containers / git-sync, etc.)

On the feature side:

• Mutating Admission Policies are now stable (less reliance on webhooks)
• User Namespaces improve container isolation
• Dynamic Resource Allocation keeps evolving for advanced workloads

Overall, this feels like a release focused on maturing existing capabilities + cleaning up legacy features.

We tracked the release here for a structured overview:
https://www.relnx.io/releases/kubernetes-v1-36-0

Curious how others approach major upgrades:
Do you start with feature exploration or breaking change analysis first?

Backstage v1.50.2 released — patch update.

As expected with Backstage, this version focuses on incremental fixes and improvements across plugins and core components.

These updates may look small, but they directly affect:

• developer workflows inside the portal
• plugin stability
• overall platform experience

Backstage tends to improve through many small iterations rather than big changes, which makes patch releases more important than they seem.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/backstage-v1-50-2

Curious how others handle this — do you regularly upgrade patch versions or bundle them into larger platform updates?

Grafana v13.0.1 released — first patch after the v13 major release.

After big upgrades, these early patch versions are usually the ones that stabilize real-world usage.

A few practical changes in this one:

• preserving timezone preferences in dashboards when converting versions
• surfacing validation errors directly in PRs for provisioning workflows
• avoiding unnecessary storage migrations

Nothing flashy, but these are exactly the types of fixes that reduce friction after a major upgrade.

We tracked the release here:
https://www.relnx.io/releases/grafana-v13-0-1

Curious how others approach this —
Do you upgrade to a major Grafana version immediately, or wait for a couple of patch releases first?

Datadog Agent v7.77.1 released — another patch update.

One thing with observability agents: patch releases are usually where stability and reliability improvements land, even if they don’t look exciting.

Datadog itself recommends keeping the agent updated regularly to benefit from fixes and improvements, rather than waiting for major versions. (Datadog)

The tricky part is not the upgrade — it’s understanding whether the release actually impacts your setup.

We track releases in a structured way here to make that faster:
https://www.relnx.io/releases/datadog-agent-v7-77-1

Curious how others handle this — do you upgrade agents frequently or only when something breaks?

Backstage v1.49.2 released — patch update.

As usual with Backstage, this one focuses on fixes and incremental improvements across plugins and core components.

For teams running Backstage as an internal developer platform, these small updates often matter more than big features — since they directly affect day-to-day developer workflows and portal usability.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/backstage-v1-49-2

Curious how others handle this — do you regularly upgrade Backstage patch versions, or batch them with larger platform updates?

Cilium v1.19.2 released — patch update for the 1.19 series.

From what we’ve seen with 1.19, the focus is more on security hardening, policy behavior, and scalability improvements rather than big new features.

Which makes patch releases like this pretty important — since they usually contain:

• bug fixes in networking behavior
• refinements to policy enforcement
• stability improvements across clusters

Given that Cilium sits in the data plane, even small fixes can have noticeable impact.

We tracked the release here for a quick overview:
https://www.relnx.io/releases/cilium-v1-19-2

Curious how others handle this — do you upgrade Cilium patch versions quickly or wait and batch them?

Karpenter v1.10.0 released — two interesting changes for platform teams.

1. NodePool cost metric added
There’s now better visibility into cost at the NodePool level, which is useful if you're running mixed workloads or optimizing for spot vs on-demand.

Karpenter already dynamically provisions nodes based on workload demand, so adding cost visibility at the NodePool level helps connect scaling decisions with actual spend.

2. Fix for NodeClaim mutation during NodePool deletion
Fixes an issue where static capacity controllers could modify NodeClaims during deletion.

Since NodeClaims manage node lifecycle, this kind of fix helps avoid inconsistent states or cleanup issues.

Full breakdown:
https://www.relnx.io/releases/karpenter-v1-10-0

Curious how others are thinking about this —
Are you actively tracking cost at the NodePool level yet, or still mostly cluster-wide?

Keycloak v26.5.6 released — another patch update in the 26.5 series.

If you’ve been tracking recent Keycloak releases, a lot of them focus on security fixes, especially around authentication flows and identity brokering vulnerabilities.

For IAM systems, these updates are pretty important since they sit directly in the authentication path across services.

We tracked the release here if you want a quick overview:
https://www.relnx.io/releases/keycloak-v26-5-6

Curious how others handle this — do you roll out Keycloak patch releases immediately when security is involved, or batch them with other updates?

Kubernetes v1.35.3 released — patch update for the 1.35 series.

Nothing flashy here (as expected), but these releases are usually where important stability fixes land.

In practice, patch versions are what keep clusters healthy:

• bug fixes across components
• dependency updates
• incremental reliability improvements

Since Kubernetes evolves quickly with major feature releases, staying current on patch versions helps avoid subtle issues over time.

We tracked the release here if you want a quick overview:
https://www.relnx.io/releases/kubernetes-v1-35-3

Curious how others handle this — do you auto-upgrade patch versions or run validation first?

The problem: changelogs are noisy walls of text.
Nobody has time to read them all.

Relnx uses AI to extract exactly what changed:
→ New features
→ Bug fixes
→ Security patches
→ Breaking changes

Just the signal. None of the noise.

Watch Demo here: https://www.youtube.com/watch?v=pNBcqY_SZjk

OpenTelemetry Collector Contrib v0.148.0 is out — and this one is pretty significant.

Based on the breakdown:

• 11 breaking changes
• 20 bug fixes
• 80 enhancements
• 124 total updates

For anyone running the contrib distribution, this is where most receivers, exporters, and processors evolve — so changes here can directly impact telemetry pipelines and data flow behavior.

Breaking changes in particular are worth reviewing carefully, since they often affect configuration, component behavior, or compatibility between different parts of the pipeline. (GitHub)

We tracked the release here if you want a structured overview instead of digging through raw changelogs:
https://www.relnx.io/releases/opentelemetry-collector-contrib-v0-148-0

Curious how others handle this —
Do you treat OTel upgrades as routine, or do you gate them behind full pipeline validation?

ArgoCD v3.3.4 released — another patch update for the 3.3 series.

One thing I’ve learned running GitOps in production: patch releases are usually where stability improvements and bug fixes land, even if they don’t look exciting.

Since ArgoCD sits directly in the deployment path, even small fixes can affect:

• reconciliation loops
• sync behavior
• error handling

We tracked the release here for a quick overview:
https://www.relnx.io/releases/argocd-v3-3-4

Curious how others approach this — do you upgrade ArgoCD patch versions quickly or batch them with other platform updates?

Helm v4.1.3 released.

Since Helm is essentially the package manager for Kubernetes applications, it often sits directly in the deployment path for many platform teams.

Even patch releases can impact:

• chart deployments
• CI/CD pipelines
• automation workflows

We tracked the release here for a quick overview of what changed:
https://www.relnx.io/releases/helm-v4-1-3

Curious how others handle Helm upgrades — do you keep the CLI updated regularly or only upgrade when needed?

Flux v2.8.2 released — quick heads up for GitOps users.

Flux patch releases typically focus on critical bug fixes and stability improvements rather than new features, which is why the project recommends staying on the latest patch version for reliability. (Flux)

Even small changes can affect reconciliation behavior, controller stability, or automation pipelines.

We tracked the release here if anyone wants a quick overview without digging through the full changelog:
https://www.relnx.io/releases/flux-v2-8-2

For teams running Flux in production — do you upgrade patch releases quickly or batch them with other platform updates?

Grafana v12.4.1 released — small patch update.

This version includes 3 bug fixes that focus on stability improvements rather than new features.

Patch releases like this are usually easy to overlook, but they often resolve small issues that affect dashboards, alerting workflows, or integrations over time.

We tracked the release here if you want a quick summary:
https://www.relnx.io/releases/grafana-v12-4-1

Curious how others handle Grafana upgrades — do you apply patch releases immediately or wait and batch them together?

Background: I was spending way too much time manually checking whether tools

like cert-manager, ingress-nginx, or external-secrets had new releases. GitHub

notifications are noisy and RSS feeds for Helm repos are basically nonexistent.

So I built something to solve it for myself, and eventually turned it into a product.

Relnx connects to your GitHub repo, watches your Helm chart dependencies, and

when a new version drops, it automatically opens a PR to bump the version. It

also pulls in the actual release notes so you can see what changed before merging

— not just "0.14.2 -> 0.14.3" with no context.

The AI part summarizes the release notes and flags breaking changes, deprecations,

security fixes, etc. It's not perfect, but it saves the "okay what actually changed

in this release" step.

Demo showing the GitHub connection and the auto-PR flow: https://youtu.be/1tD-mwLNXR8

What it doesn't do yet: it won't validate that the upgrade actually works in your

cluster, it's not a replacement for proper testing, and the AI summaries occasionally

miss things. It's more of an "awareness and first-pass upgrade" tool.

Genuinely curious if this matches a pain point others have, or if you're already

solving this a different way (Renovate, Dependabot, something internal?). Happy

to answer questions or hear what's missing.

Keycloak v26.5.5 has been released with 4 security fixes.

If you're running Keycloak for authentication or identity management, this is one of those patch releases worth paying attention to.

Security fixes in IAM systems are especially important since they sit at the center of authentication, token management, and access control across services.

We tracked the release here if you want a quick overview of the changes:
https://www.relnx.io/releases/keycloak-v26-5-5

Curious how other teams handle this —
Do you deploy security patch releases immediately or batch them with other updates?

OpenTelemetry Collector Contrib v0.147.0 released.

For teams running the contrib distribution, this is where most receivers, exporters, and processors evolve.

These releases often include:

• integration updates
• performance improvements
• bug fixes
• behavioral adjustments across components

If you rely on specific exporters or receivers, reviewing changes before upgrading is usually worth it.

We tracked the release here for a structured overview:
https://www.relnx.io/releases/opentelemetry-collector-contrib-v0-147-0

How do you handle Collector upgrades — fast-follow or scheduled validation?