API Evolution

[fleXive] tries to provide a stable API for developing enterprise applications. However, sometimes we have to change method signatures to incorporate new functionality. In this process, the "old" method is marked as @Deprecated and the JavaDoc should point to the new, preferred method.

All classes of the com.flexive.shared hierarchy are considered public and stable (this includes all EJB interfaces).

Unless explicitly stated, all classes in the flexive-shared package are public and should not make incompatible changes.

JSF applications can rely on the com.flexive.faces helper classes not making backwards-incompatible changes.

This includes mostly the FxJsfUtils class and basic managed beans. However the component implementations are subject to change at any time, they probably would also not be suited well for subclassing.

When a method is deprecated, it will be marked as deprecated in at least one major release.

If a method was deprecated in 3.1.0, it can be removed in version 3.2 (it was already deprecated in 3.1). If it was deprecated in 3.1.1, it would be removed in 3.3 (since 3.2 would be the first major release to include it).

Deprecated methods are removed in major releases, never in minor releases.

If a application compiles against the first version of a major release, it should also compile against all following minor releases.