OK, taking a cue from Mozilla's XPCOM... what do we think about making a distinction between frozen and non-frozen interfaces? Simply put, frozen interfaces never change, while non-frozen interfaces can change. I'd imagine that:
a) new interfaces are non-frozen until a release
b) all end-user interfaces (e.g., org.apache.beehive.controls.api.bean.Extensible) get frozen at a release
c) internal/advanced interfaces (e.g., org.apache.beehive.netui.pageflow.ServerAdapter) don't necessarily get frozen, so implementors may have to add or change methods when upgrading to a new release.


If we did this, we could have a simple annotation to denote frozen interfaces, like @frozen.

The alternative, of course, is to assume *all* interfaces are frozen at a release: we can never change signatures, and if we ever want to add something, we add a new interface (ServerAdapter2, ServerAdapter3, etc.) in the Microsoft vein.

Thoughts?

Rich

Reply via email to