|
| 1 | +# OpenTelemetry Java Versioning |
| 2 | + |
| 3 | +## Compatibility requirements |
| 4 | + |
| 5 | +This codebase strictly follows [Semantic Versioning 2.0.0](https://semver.org/). This means |
| 6 | +that all artifacts have a version of the format `MAJOR.MINOR.PATCH` or `MAJOR.MINOR.PATCH-alpha`. |
| 7 | +For any artifact with a stable release, that is its version does not end in `-alpha`, no backwards-incompatible |
| 8 | +changes will be made unless incrementing the `MAJOR` version number. In practice, this means that |
| 9 | +backwards-incompatible changes will be avoided as long as possible. Most releases are made by |
| 10 | +incrementing the `MINOR` version. Patch releases with urgent cherry-picked bugfixes will be made by |
| 11 | +incrementing the `PATCH` version. |
| 12 | + |
| 13 | +A backwards-incompatible change affects the public API of a module. The public API is any public |
| 14 | +class or method that is not in a package which includes the word `internal`. Examples of incompatible |
| 15 | +changes are: |
| 16 | + |
| 17 | +- API changes that could require code using the artifact to be changed, e.g., removing a method, |
| 18 | + reordering parameters, adding a method to an interface or abstract class without adding a default |
| 19 | + implementation. |
| 20 | + |
| 21 | +- ABI changes that could require code using the artifact to be recompiled, but not changed, e.g., |
| 22 | + changing the return type of a method from `void` to non-`void`, changing a `class` to an `interface`. |
| 23 | + The [JLS](https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html) has more information on |
| 24 | + what constitutes compatible changes. |
| 25 | + |
| 26 | +- Behavior changes that can require code using the artifact to be changed, e.g., throwing an exception |
| 27 | + in code that previously could not. Note, the opposite is not true, replacing an exception with a |
| 28 | + no-op is acceptable if the no-op does not have a chance of causing errors in other parts of the |
| 29 | + application. |
| 30 | + |
| 31 | +Such changes will be avoided - if they must be made, the `MAJOR` version of the artifact will be |
| 32 | +incremented. |
| 33 | + |
| 34 | +Backwards incompatible changes to `internal` packages are expected. Versions of published artifacts |
| 35 | +are expected to be aligned by using BOMs we publish. We will always provide BOMs to allow alignment |
| 36 | +of versions. |
| 37 | + |
| 38 | +As a user, if you always depend on the latest version of the BOM for a given `MAJOR` version, and |
| 39 | +you do not use classes in the `internal` package (which you MUST NOT do), you can be assured that |
| 40 | +your app will always function and have the latest features of OpenTelemetry. |
| 41 | + |
| 42 | +## API vs SDK |
| 43 | + |
| 44 | +This codebase is broadly split into two large pieces, the OpenTelemetry API and the OpenTelemetry SDK, |
| 45 | +including extensions respectively. Until a `MAJOR` version bump, all artifacts in the codebase, both |
| 46 | +for API and SDK, will be released together with identical `MAJOR.MINOR.PATCH` versions. If one of the |
| 47 | +two has its `MAJOR` version incremented independently, for example SDK v2 is released while still |
| 48 | +targeting API v1, then all artifacts in that category will be released together. The details for this |
| 49 | +will be fleshed out at the time - it can be expected that the repository is split in some way to |
| 50 | +ensure all artifacts within a single repository are at the same version number. |
| 51 | + |
| 52 | +When incrementing the `MAJOR` version of the API, previously released `MAJOR` versions will be supported |
| 53 | +for at least three more years. This includes |
| 54 | + |
| 55 | +- No backwards incompatible changes, as defined above |
| 56 | +- A version of the SDK supporting the latest minor version of this API will be maintained |
| 57 | +- Bug and security fixes will be backported. |
| 58 | +- Additional features generally will not be backported |
| 59 | + |
| 60 | +When incrementing the `MAJOR` version of the SDK, previously released `MAJOR` versions will be supported |
| 61 | +for at least one year. |
| 62 | + |
| 63 | +## Stable vs alpha |
| 64 | + |
| 65 | +Not all of our artifacts are published as stable artifacts - any non-stable artifact has the suffix |
| 66 | +`-alpha` on its version. NONE of the guarantees described above apply to alpha artifacts. They may |
| 67 | +require code or environment changes on every release and are not meant for consumption for users |
| 68 | +where versioning stability is important. |
| 69 | + |
| 70 | +When an alpha artifact is ready to be made stable, the next release will be made as usual by bumping |
| 71 | +the minor version, while the `-alpha` suffix will be removed. For example, if the previous release |
| 72 | +of `opentelemetry-sdk` is `1.2.0` and of `opentelemetry-sdk-metrics` is `1.2.0-alpha`, the next |
| 73 | +release when making metrics stable will have both artifacts with the version `1.3.0`. Notably, |
| 74 | +`MAJOR` versions are only used to indicate a backwards-incompatible change and are not used to |
| 75 | +announce new features. |
0 commit comments