ARC Best Practices » Changes to interfaces
en

Changes to interfaces

Constraints

Standard and Stable interfaces cannot change incompatibly (more correctly, cannot remove support for the previous version, even if a new version can coexist) until either:

  1. A major release of the product (which is not envisioned for Solaris), or
  2. The end-of-life process for features is followed; this requires demonstrating that the interface is Obsolete -- i.e., generally unused -- often because a better alternative exists and has "universal" acceptance.

Evolving interfaces are not normally changed incompatibly. Such a change would necessitate thoughtful justification to the committee. Committed Private and Sun Private interfaces have much the same restriction, but incompatible change can be allowed if it is sufficiently hidden from the customer or otherwise "managed" so that "normal use" is not affected by the interface's evolution.

Making a change to an existing interface

If any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion.

Being prepared for future evolution

Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution?

Tags:
Created by admin on 2009/10/26 12:07
Last modified by Asa Romberger on 2010/02/26 22:22

Collectives

Community Group arc Pages


XWiki Enterprise 2.7.1.34853 - Documentation