Publishing guide

This documents the process of publishing of a new release of scala-xml.

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 publishing. This is possible because the 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 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.

After you make a release, you'll need to bump at least the minor version number in build.sbt.

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 also try to self-compile the compiler and need its dependencies (including scala-xml) built for the new major version. 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