The following outlines the strategy for managing versioned releases of Dagger 2.
All versions of Dagger 2 are of the form
A change to
PATCH indicates that a release is fully compatible with the
previous release. Upgrading should be considered a drop-in replacement.
A change to
API indicates that the release contains a change to the public
API. (Adding a new compiler error is considered a change to the public API.)
API releases are expected to be compatible with previous versions, but
users are advised to read the release notes for a description of the changes
and a description of any associated risk.
Dagger APIs are classified as either
@Beta or non-
@Beta and have
separate policies for change.
Dagger uses the
@Beta annotation to signal the same intent as that of Guava:
“APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard).”
We will try to minimize churn, but since
@Beta features are typically newer
features under active development, we cannot guarantee their stability.
@Beta APIs are much more stable. API changes are typicially backwards-
compatible and mostly the result of the proven stability of a previously
@Beta API (i.e. removing the
But, a non-
@Beta API may change in incompatible ways on rare occasions. Any
breaking change will happen at least 6 months after warning documentation
@Deprecated) is added, and will always include migration
For features that will be introduced in the upcoming release, use NEXT as the
API][#version-policy] version. These will be updated as part of the release
As of March 2016, the Dagger team is aiming to produce a versioned release every
2 weeks. This is not a strict schedule, but a goal to ensure that changes made
HEAD are available within approximately 2 weeks.