Publishing guide
This documents the process of publishing of a new release of scala-xml. It assumes you're already familiar with material described in the Maintainer guide.
Publishing with Sonatype is accomplished by the scala-module sbt plugin:
https://github.com/scala/sbt-scala-module
Whenever a tag is pushed, Travis does the task of building and publishing the release. This is possible because the Sonatype credentials are encrypted in .travis.yml.
https://travis-ci.org/scala/scala-xml
See also the admin/build.sh shell script in the repo that Travis calls.
GitHub has a Web interface for pushing a tag and documenting the release:
https://github.com/scala/scala-xml/releases/new
You should try to document what has changed in the release. You can use the release notes of previously released versions as examples.
The only part of the above that is not automated requires the Scala compiler team at Lightbend, Inc. They will do one last sanity check and then manually close and release the staging repos on Sonatype to allow the artifacts to proceed to Maven Central.
The API docs for the release can be published with the shell script admin/api-docs.sh:
./admin/api-docs.sh v1.2.0 2.13.0
cd jvm/target
git log
git push upstream gh-pages
After you make a release, you'll need to bump the minor version number (at the least) in build.sbt, and the mimaPreviousVersion.
The Maven badge will automatically update after a release, but if there is a new version of Scala you may need to update or add a Maven badge.
Someone at Lightbend can probably help you post something to Twitter. Previous tweets: