Migration to Sonatype Central Portal

[samspills]

OSSRH is end-of-life on June 30 2025
Migration info: https://central.sonatype.org/faq/what-is-different-between-central-portal-and-legacy-ossrh/#process-to-migrate

Vague steps / ideas to follow. This is very much a work in progress and I'm just trying to get some thoughts out of my brain and onto paper (as it were)

1. sbt-typelevel already supports central however there was an issue with bundle upload timeouts during testing. This has been addressed in fix: Increase timeout lumidion/sonatype-central-client#22 (no release or snapshot of this yet), but we need that released and updated in sbt-sonatype and then sbt-sonatype released and updated in sbt-typelevel
   • sbt-sonatype issue to track: Bundle upload times out after switching to Sonatype Central xerial/sbt-sonatype#597
2. Work with Sonatype to migrate org.typelevel (currently necessary because we have more than 6 authorized publishers)
   • Doobie, skunk, natchez are published to org.tpolecat but I don't know how many publishers are authorized there or if we need Sonatype involved there as well
   • co.fs2 (same question about number of authorized publishers)
   • are there any other group IDs we publish to that I've forgotten?
   • they will likely be very busy with requests, so ideally we should not leave this to the last week 😅
3. migration guide for individual projects?
   • ThisBuild / sonatypeCredentialHost (note to self: need to update sbt-typelevel Customization docs to point to this setting)
   • snapshot publishing? I know Central didn't support snapshots at first and now it does, does sbt-typelevel support Central snapshots? Will projects need to make changes? (I haven't kept track of this situation)
     • Restore support for SNAPSHOTs on Sonatype Central sbt-typelevel#784
     • above depends on Support to publish snapshots to Central Sonatype xerial/sbt-sonatype#564

[rossabaker]

I have a toy project where I'm taking notes. I had to use Java 11 in the workflow, but that might be relaxing.

[mzuehlke]

Ongoing work to make sbt-sonatype JDK 8 compatible again: xerial/sbt-sonatype#583

[samspills]

I migrated the pink.cozydev namespace as a guinea pig. Here are my rough notes about the process:

• created the PR first: switch to Sonatype Central host cozydev-pink/snakecase#117
• pressed the button to migrate the namespace in https://central.sonatype.com/publishing/namespaces
  • it said it would take several minutes, but it was pretty quick for me
• regenerated the sonatype user token and updated the user+pass in the org github secrets
• merged the PR
• created an RC release (this was maybe 30 minutes after the namespace migration?)
  • publish job: https://github.com/cozydev-pink/snakecase/actions/runs/15003183440/job/42155253286
  • took ~22 minutes to publish, but everything went totally fine

HOWEVER!!
I tried to create a v0.0.5 that was simply promoting the same commit from the RC, but that publish job failed because it was still picking up the RC3 tag to name the artifacts, so of course it conflicted.
I'm very nearly positive that this has been fine in the past with sbt-typelevel + OSSRH, so something is different with the process for Central(?). I have not investigated why this is yet, just getting my notes down
TIL I am wrong about this! sbt-typelevel selects the tag by sorting and taking the last and the sorting of tags puts RCs after the full tag. I will open an issue to discuss further in sbt-typelevel, but this isn't at all related to Central 😅

[rossabaker]

http4s just got eaten by sbtPluginPublishLegacyMavenStyle not being false.

https://github.com/xerial/sbt-sonatype/blob/master/README.md#sonatype-central-host

[rossabaker]

org.http4s is moved and at least two projects are successfully publishing via sbt-sonatype. I am up for asking Sonatype to move us if we're ready to take the plunge.

[rossabaker]

I was ready to flip the switch this morning, but reflecting on how org.http4s went (thus far: smoothly!), I think we want typelevel/sbt-typelevel#821 first.

[rossabaker]

I don't recommend anyone use this long term, but there is a milestone published to my personal org to test sbt-typelevel's self-publication, and it could be tested on affiliates or personal orgs that have less heft to move than org.typelevel.

[rossabaker]

This effort is spanning repos and tickets, so centralizing the progress here:

• ask for Sonatype to move us
• cut sbt-typelevel-0.8.0-RC1
• cut a release of some arbitrary Typelevel project on that RC to be sure
• cut sbt-typelevel-0.8.0
• release the hounds

[rossabaker]

I am merging sbt-1.11 PRs aggressively across the organization, even on projects I don't actively maintain, just so they're ready when Scala Steward runs.

[valencik]

as a rough checklist:
https://github.com/search?q=org%3Atypelevel+is%3Apr+%22Update+sbt%2C+scripted-plugin+to+1.11.1%22&type=pullrequests

[rossabaker]

These projects all have a failing build on the 1.11 PR and will be unable to publish until it's addressed. The rest have been merged or slipped through the Steward cracks.

[rossabaker]

We got moved shortly after I selfishly went to bed. In case anyone scores a perfect 10 on CVE while the rest of the checklist finishes, the RC is publishing, or in the worst case "com.rossabaker" % "sbt-typelevel" % "0.8.0-rab.4" has worked.

[samspills]

Arbitrary project release with sbt-typelevel v0.8.0-RC1 is a success

• the PR to bump sbt-typelevel Upgrade to sbt-typelevel-0.8.0-RC1 scalacheck-xml#218
• snapshot published after merging the PR successfully (link to action job, just for reference)
• scalacheck-xml v0.1.1 tagged and published (link to action job, just for reference)