publishToMavenCentral() uploads a deployment to the Central Portal and stops there. Somebody has to
open the portal and press Publish before an artifact resolves, and until they do, a release that is
green everywhere else does not exist to a consumer.
It has already been forgotten once. The 2.0.0 deployment sat unpublished, and 2.2.0 reached the same
state: tag, GitHub Release, attestations, CLI binaries attached, and
implementation("io.github.nacode-studios:kdrant-transport-rest:2.2.0") resolving nothing until the
button was found. The failure mode is quiet by construction, because every check is green.
There are two honest answers and the wrong one is leaving it as it is.
Automate it. The publishing plugin takes publishToMavenCentral(automaticRelease = true), which
releases the deployment once validation passes. The argument against is that the manual step is the last
place to notice something wrong before an artifact becomes permanent, and Maven Central has no unpublish.
That argument is worth stating rather than assuming, because in practice nobody inspects the staged
deployment: they press the button because the workflow was green, which is a check that has already run.
Or keep it and make it a step. If the pause is worth having, the release issue lists it as work
rather than leaving it to memory, and something reports the deployment as pending instead of the release
looking finished. A manual step nobody is told about is not a gate, it is a way to forget.
Either way the release checks what it claims. release.yml can poll repo1.maven.org for the new
version and say so in the run summary, which turns "published" from an assumption into an observation.
The version matrix already works that way, and the compatibility table is the better for it.
Exit criterion: publishing is either automatic, or a named step of the release with a check that reports
whether the version resolves from Maven Central, and no release can read as finished while its artifacts
are still staged.
publishToMavenCentral()uploads a deployment to the Central Portal and stops there. Somebody has toopen the portal and press Publish before an artifact resolves, and until they do, a release that is
green everywhere else does not exist to a consumer.
It has already been forgotten once. The
2.0.0deployment sat unpublished, and2.2.0reached the samestate: tag, GitHub Release, attestations, CLI binaries attached, and
implementation("io.github.nacode-studios:kdrant-transport-rest:2.2.0")resolving nothing until thebutton was found. The failure mode is quiet by construction, because every check is green.
There are two honest answers and the wrong one is leaving it as it is.
Automate it. The publishing plugin takes
publishToMavenCentral(automaticRelease = true), whichreleases the deployment once validation passes. The argument against is that the manual step is the last
place to notice something wrong before an artifact becomes permanent, and Maven Central has no unpublish.
That argument is worth stating rather than assuming, because in practice nobody inspects the staged
deployment: they press the button because the workflow was green, which is a check that has already run.
Or keep it and make it a step. If the pause is worth having, the release issue lists it as work
rather than leaving it to memory, and something reports the deployment as pending instead of the release
looking finished. A manual step nobody is told about is not a gate, it is a way to forget.
Either way the release checks what it claims.
release.ymlcan pollrepo1.maven.orgfor the newversion and say so in the run summary, which turns "published" from an assumption into an observation.
The version matrix already works that way, and the compatibility table is the better for it.
Exit criterion: publishing is either automatic, or a named step of the release with a check that reports
whether the version resolves from Maven Central, and no release can read as finished while its artifacts
are still staged.