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 Scala compiler can then have its dependency for scala-xml updated to the new version. Someone at Lightbend will initiate this upgrade assuming the compiler team is amenable to it.

The bootstrap process in Scala will try to self-compile the compiler and its dependencies (including scala-xml) for new major version development. If there are any changes to the build in scala-xml, the compiler's build suite will need to be updated accordingly as well.

Someone at Lightbend can probably help you post something to Twitter. Previous tweets:

https://twitter.com/search?q=%40scala_lang+scala-xml