Releasing a new version

July 31, 2025 · View on GitHub

bugsnag-android is released via Sonatype. If you are a project maintainer you can release a new version by unblocking the publish step on CI and following the steps below.

Pre-release checklist

This contains a prompt of checks which you may want to test, depending on the extent of the changeset:

  • Has the full test suite been triggered on Buildkite and does it pass?
  • Have versions of Android not covered by CI been considered?
  • Does the build pass on the CI server?
  • Are all Docs PRs ready to go?
  • Do the installation instructions work when creating an example app from scratch?
  • Has all new functionality been manually tested on a release build?
    • Ensure the example app sends an unhandled error
    • Ensure the example app sends a handled error
    • If a response is not received from the server, is the report queued for later?
    • If no network connection is available, is the report queued for later?
    • On a throttled network, is the request timeout reasonable, and the main thread not blocked by any visible UI freeze? (Throttling can be achieved by setting both endpoints to "https://httpstat.us/200?sleep=5000")
    • Are queued reports sent asynchronously?
  • Native functionality checks:
    • Rotate the device before notifying. Is the orientation at the time persisted in the report on the dashboard?
    • Rotate the device before causing a native crash. Is the orientation at the time of the crash persisted in the report on the dashboard?
    • Wait a few seconds before a native crash. Does the reported duration in foreground match your expectation? Is the value for "inForeground" correct?
    • Do the function names demangle correctly when using notify?
  • Have the installation instructions been updated on the dashboard as well as the docs site?
  • Do the installation instructions work for a manual integration?

Making the release

  • Check the performance benchmarks against the baseline to confirm there are no serious regressions
  • Create a new release branch from next -> release/vN.N.N
  • Pull the release branch and update it locally:
    • Update the version number with make VERSION=[number] bump
    • Inspect the updated CHANGELOG, README, and version files to ensure they are correct
  • Open a Pull Request from the release branch to main
  • Once merged:
    • Pull the latest changes (checking out main if necessary)
    • On CI:
      • Trigger the release step by allowing the Trigger package publish step to continue
      • Verify the Publish step runs correctly and the artefacts are upload to sonatype.
    • Release to GitHub:
    • Checkout main and pull the latest changes
    • Test the changes in the example app with rm -rf ~/.m2/repository/com/bugsnag and ./gradlew publishToMavenlocal
    • "Promote" the release build on Maven Central:
      • Go to the sonatype open source dashboard
      • Select the com.bugsnag deployments
      • Ensure that AARs and POMs are present for each module
      • Click the “Publish” button in the toolbar, no message
      • Click the “refresh” button and see the deployment status change to "Published"
    • Merge outstanding docs PRs related to this release
    • Raise PRs to update the bugsnag-android dependency for bugsnag-js, bugsnag-unity, bugsnag-flutter and bugsnag-unreal

Post-release checklist

(May take some time to propagate to maven central)

  • Have all Docs PRs been merged?
  • Can a freshly created example app send an error report from a release build using the released artefact?
  • Do the existing example apps send an error report using the released artifact?
  • Make releases to downstream libraries, if appropriate (generally for critical bug fixes)

Manual publishing

Manual publishing is discouraged, but is possible in exceptional circumstances by running ./gradlew assembleRelease publish. This also requires creating a GPG key and registering an account with Sonatype.

Creating a GPG key

  • Create a GPG key if you haven't got one already (gpg --full-gen-key and select RSA/4096bit). The build system requires a GPG key ring set up using GPG 1.x, but many systems now ship with GPG 2.x. As a workaround, after creating your key you can manually create the secring.gpg file by running gpg --export-secret-keys >~/.gnupg/secring.gpg

  • Create a Sonatype JIRA account

  • Ask in the Bugsnag Sonatype JIRA ticket to become a contributor

  • Ask an existing contributor (likely Simon) to confirm in the ticket

  • Wait for Sonatype to confirm the approval

  • Create a file ~/.gradle/gradle.properties with the following contents:

    # Your credentials for https://oss.sonatype.org/
# NOTE: An equals sign (`=`) in any of these fields will break the parser
# NOTE: Do not wrap any field in quotes

NEXUS_USERNAME=your-nexus-username
NEXUS_PASSWORD=your-nexus-password
nexusUsername=your-nexus-username
nexusPassword=your-nexus-password

# GPG key details
# See https://central.sonatype.org/publish/requirements/gpg/ for full documentation
# Your key must be added to a public key server, such as http://keyserver.ubuntu.com:
# 1. Get your key id by running `gpg --list-keys --keyid-format=short`. It
#    should be 8-character hexadecimal.
# 2. Export your key using `gpg --armor --export <key-id>`
# 3. Distribute your public key: `gpg --keyserver keyserver.ubuntu.com --send-keys`
signing.keyId=<key-id>
signing.password=your-gpg-key-passphrase
signing.secretKeyRingFile=/Users/{username}/.gnupg/secring.gpg