Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] proposed package naming convention to distinguish 'work in progress' API


On the issue of "provisional APIs" .... I'll document here the position the WTP Architecture Group which discussed
this issue in last meeting. Initially, we were unanimously agreed anything that's not API should not be identified
as "proposed API" via package names but instead through other forms of JavaDoc and "proposal documents" for
"future releases". But, as we continued to discuss areas we would (likely) recommend that *not* be API in release 1,
it became apparent there could easily be some cases where it might improve review and feedback for iterative
design -- so, we would not object to "internal.provisional" in package names as long as 1) the correct expectation
is set that there is no guarantee of future compatibility (possibly not even in maintenance stream/fixes), so
clients have to be prepared to respond, if they use it, as they would any other "internal" use, and 2) the use of
"internal.provisional" should not be used lightly ... component leads would be expected to have some degree
justification  for using it (such as the best justification would be: "known clients willing to use 'internal'
classes, desired future API function, but planned to be moving to a different project next release" or similar).
As Arthur said, its use it optional, and there are other ways of "giving hints" as to future proposed API
functionality.

I think this is all consistent with the sum total of previous comments posted to wtp-dev (its meant to be), and
I'm just trying to publically document Architecture Groups concerns and discussion of it.

Community feedback welcome, especially as specific cases begin to be seen.

Back to the top