Advance widely used functionality to a stable version

Libraries at 0.x versions and unstable features (which should be marked with annotations if they live in a stable library, as outlined in JLBP-3) make no promises about stability. If they become widely used, they can cause problems when there are surface breakages (which is allowed per the rules of unstable functionality, explained in JLBP-3). If such breakages can cause widespread pain, the unstable features can become de facto GA. Promote widely-used unstable libraries and features to 1.0 and commit to their APIs, even if the functionality is not complete. Stability is not about completeness but about guarantees not to break users’ code frequently.

If the surface needs to change before it stabilizes, follow the process in JLBP-7 to minimize disruption to the ecosystem. (TL;DR: Mark the old surface @Deprecated and add the new surface in phase 1, delete the old surface in phase 2). However, if it would take a long time for the ecosystem to complete phase 2 (remove all references to the old surface), consider promoting the library or feature to stable before phase 2 is completed because there is more value to having a stable surface than there is to having a surface with zero deprecated methods.

To avoid getting stuck in the first place, do not evangelize your pre-1.0 library or suggest that other teams and projects depend on it.

Once the API is stable and has reached 1.0 is the time to seek customers, not before.