I'll need to customize sbt-dynver to get the right handling of tags; we want a tag such as s-9.7.1 to result in a version such as 9.7.1-scala-1. The old publishing setup had code for this: git.gitTagToVersionNumber := ...

see https://github.com/sbt/sbt-dynver?tab=readme-ov-file#custom-version-string

Also I ripped out sbt-scala-module as I'd rather have a self-contained build, but I need to make sure that everything we were getting from it gets duplicated here. For example setting organization.

see https://github.com/scala/sbt-scala-module/blob/main/src/main/scala/ScalaModulePlugin.scala

decided to just make setting version a manual step

perhaps this will need some further tweaking once I actually try to publish

of course I had to do the usual rigmarole of generating a GPG key and adding the four secrets (as documented in sbt-ci-release readme) to our repo secrets, remembering to use our Sonatype user token and not our plain name/password

two tweaks so far:

• add <developers> stuff, Sonatype requires it
• remove a stray versionCheck that I cargo-culled into release.yml

that was enough for the publishing job to apparently succeed: https://github.com/scala/scala-asm/actions/runs/12405290988

but once it's on Maven Central I want to diff the JARs against scala-asm-9.7.0-2 to see if any unintended changes crept in

it published: https://repo1.maven.org/maven2/org/scala-lang/modules/scala-asm/9.7.1-scala-1/

diffing the POMs, I don't know what this is about:

-    <packaging>bundle</packaging>
+    <packaging>jar</packaging>

the other diffs are just unimportant metadata differences

as for the JAR contents:

• we are no longer generating the scala-asm.properties file that sbt-scala-module used to provide, but I really don't think we care
• MANIFEST.MF no longer has the OSGi stuff, as expected

diffing the POMs, I don't know what this is about:

-    <packaging>bundle</packaging>
+    <packaging>jar</packaging>

Oh, that's just a consequence of not doing OSGi anymore.