This document address a variety of versioning and release considerations for the OpenTelemetry Android project.
This codebase uses Semantic Versioning (semver) for its version numbers. All modules in this codebase are released at the same time and, as such, will be versioned together. All modules in this repo are released with the same version number.
Until 1.0.0 stability has been achieved, regular releases will only typically increment the minor version (second number in the semver triplet). Patch releases are considered exceptional, and will only be created if a critical issue needs to be addressed shortly after a regular release.
Every commit to the main branch will cause a
snapshot build
to be published to Sonatype. Users may choose to build and test and file issues against SNAPSHOT
builds, but their use in production is strongly discouraged.
The android-agent currently supports the following minimum versions:
- Kotlin 2.0
- API 23+ (desugaring of the core library required for API <26)
- Android Gradle Plugin (AGP) 7.4 and Gradle 7.5
- JDK 11 (build-time)
- Java language level 8 as per opentelemetry-java
These versions can be bumped in a major version release when:
- Google Play Services drops support for any of the above versions
- A new version of Kotlin is released that drops support for the minimum Kotlin version that opentelemetry-android targets. In practice, Kotlin usually supports the last 4 minor versions of Kotlin.
- At the discretion of maintainers after discussing in the SIG
These are minimum supported versions. We would strongly recommend using newer versions where possible as that's where our testing will be focused.
This Android library is built on top of other OpenTelemetry components:
As such, this project will follow a release schedule that is related to the upstream release schedule. Presently, this means a monthly release, typically within a week of the last release of the above components.
Java and/or Kotlin code that lives in a package with internal anywhere in the name
should be considered internal to the project. Code in internal packages is not intended
for direct use, even if classes or methods may be public.
Internal code may change at any time and carries no API stability constraints.