Experimental Features

All Park-Manager features benefit from our Backward Compatibility Promise to give developers the confidence to upgrade to new versions safely and more often.

But sometimes, a new feature is controversial. Or finding a good API is not easy. In such cases, we prefer to gather feedback from real-world usage, adapt the API, or remove it altogether. Doing so is not possible with a no BC-break approach.

To avoid being bound to our backward compatibility promise, such features can be marked as experimental and their classes and methods must be marked with the @experimental tag.

A feature can be marked as being experimental for only one minor version, and can never be introduced in a last major release. The core team can decide to extend the experimental period for another minor version on a case by case basis.

To ease upgrading projects using experimental features, the changelog must explain backward incompatible changes and explain how to upgrade code.