For most of Maven Central's history, publishing has followed a simple model: maintainers publish releases, users consume them, and when something goes wrong, the fix comes through the same channel.

That model still works most of the time. It is also the model we want to preserve.

But the world around it is changing.

A growing group of security researchers, maintainers, vendors, foundations, and infrastructure operators have been working through what AI-accelerated vulnerability discovery means for open source. The Akrites project is one part of that conversation. Its central observation is simple enough: when machines can find vulnerabilities faster than humans can coordinate fixes, the bottleneck moves. Discovery is no longer the hard part by itself. Validation, triage, disclosure, repair, and deployment become the scarce resources.

That matters for Maven Central because Central is not just a file server. It is part of the dependency graph's trust fabric. A single artifact may sit several layers deep in thousands or millions of applications. When one of those artifacts is vulnerable, the cleanest answer is always upstream repair: maintainers publish a fixed release, consumers upgrade, and the graph moves forward.

But not every project is active. Not every maintainer is reachable. Not every component still has an upstream capable of responding quickly. Some projects are end-of-life and still everywhere. Some fixes will be backports to old lines that no one expected to touch again. And in those moments, telling the world to move to a brand-new namespace is often technically correct in the way only technically correct answers can be: accurate, principled, and operationally miserable.

In Maven, coordinates are identity. Moving from one groupId:artifactId to another is not a rename. It can create duplicate classes, version collisions, broken dependency mediation, and a long tail of transitive dependency cleanup. That is not what you want during an emergency.

So we are proposing a draft policy for a narrow mechanism inside Maven Central: a way for Central, working with preapproved trusted remediation actors, to approve emergency remediation releases into existing coordinates when that is the safest path for the ecosystem.

This is intentionally a Maven Central publication policy. It defines when Central may authorize an emergency remediation release under an existing coordinate. It does not change how Maven, Gradle, repository managers, scanners, dependency bots, or other tools resolve or recommend versions.

Introducing the Maven Central CARE Program

We are calling this draft policy the Maven Central CARE Program: Central Approved Remediation for Emergencies.

CARE is intentionally narrow: ordinary maintainer publication remains the preferred path; original maintainers do not lose their rights; emergency releases must be reviewed and validated; trusted remediation actors must work in coordination with Central; and CARE releases are for security remediation, not features, modernization, rebranding, or project takeover.

Before getting into version numbers, it's worth being clear about the scope of the proposal. CARE isn't trying to decide when consumers should upgrade, how dependency bots should behave, or how scanners should prioritize findings. Those decisions remain with the broader ecosystem. The question here is much narrower: if a trusted remediation exists but the ordinary maintainer publication path isn't available, what should Maven Central publish?

The full draft has the details. This post is mostly about the shape of the idea and the part we most need the community to stress-test: versioning.

The Versioning Problem

If a vulnerable project is still maintained, the answer is easy:

But suppose 1.2.3 is vulnerable and the project is dormant. A trusted remediation actor produces a fix. Central can reproduce and validate it. The fix is narrow. The licensing checks out. Publishing under a new coordinate would make downstream remediation much harder.

What should the version be?

One option is to publish the next patch version:

That has the cleanest sorting behavior, but it consumes the maintainer's next normal version. If the maintainer later returns, we have blurred the line between an emergency remediation and an ordinary maintainer release.

Another option is to put the remediation actor in the version:

That is visible, but it creates a vendor-label race inside a legacy namespace. We do not want Central to become a place where companies publish competing branded emergency variants of someone else's artifact.

Another option is to publish the fix under a new namespace. That is clean from an ownership perspective, but painful for dependency resolution. It asks every downstream user to rewire their graph at the moment we should be lowering friction.

The draft policy proposes a different approach: create an emergency branch from the affected base version.

The -care suffix would be reserved for approved releases under the Maven Central CARE Program.

This does a few useful things.

First, it keeps the existing coordinate intact. The CARE version is still simply another published version. Whether and when downstream tooling recommends or adopts it remains outside the scope of this policy. Consumers can update within the same groupId:artifactId rather than moving to a forked coordinate and untangling the dependency graph.

Second, it does not consume the maintainer's next normal version. The original maintainer can still return and publish 1.2.4.

Third, it makes the emergency nature of the release visible. 1.2.3.1-care is plainly not a normal upstream release.

Fourth, it avoids vendor labels in the version. The remediation actor's identity belongs in metadata, VEX, provenance, and Central-facing records, not as a competing suffix in the artifact version.

This is the part where we especially want feedback. Maven version ordering has history in it, as all good build systems eventually do. We want the version form to be understandable to humans, workable for tools, and boring enough that it does not become its own problem.

What CARE Would Not Mean

A CARE release would not mean the original maintainer endorsed the fix.

It would not mean the original maintainer lost the namespace.

It would not mean the trusted remediation actor became the project maintainer.

It would not authorize feature work, modernization, rebranding, commercial extensions, or a new roadmap under the legacy coordinate.

It would not change how Maven, Gradle, or other tools resolve dependency versions, nor modify or replace existing releases already published in Maven Central.

If a project needs ongoing new stewardship, that is a different process. In many cases, that work should happen under a successor namespace. CARE is for emergency remediation where continuity of the existing coordinate materially improves safety.

What We Need Feedback On

We are publishing this as a request for comments because both the versioning model and the boundaries of the proposal have to work in the real ecosystem, not just in a policy draft.

The question is not whether emergency remediation is hard. It is. The question is whether this proposed shape creates fewer problems than the alternatives. We're especially looking for feedback in two areas:

• First, does 1.2.3.1-care sort and resolve correctly across the ecosystem?

• Second, have we drawn the scope correctly?

In other words: tell us what is wrong, surprising, or controversial. If a tool will do something odd with this version shape, we want to know now, not during a coordinated emergency.

One of the more useful pieces of feedback we've already received is that this proposal needs to be very explicit about where Central's responsibility ends. We've updated the draft accordingly, and I'd much rather make those boundaries painfully clear now than discover ambiguities during an actual emergency.

The dependency graph is shared infrastructure. The next wave of vulnerability discovery will test whether we can repair that infrastructure with discipline, or whether we will fragment it in the name of urgency.

CARE is a proposal for doing the former: preserve coordinates where it matters, respect maintainers, validate the fix, expose the metadata, and keep emergency authority narrow.

Please read the draft policy and tell us where this versioning model holds, where it breaks, and what we missed. Share your feedback and questions in r/MavenCentral on Reddit.