For this particular case we also need to clarify the policy around internal/private/non-public classes and methods. You can specifically mark classes and methods with a special private annotation, (WLS does this today in some cases), or you can just make general statements regarding package structures of the tree, and or say only classes marked public are public and all others are internal. (WLS often does this as well).
Again to repeat, often developers have their own internal notions of the state of class/method, but these need to be communicated to the community at large holistically and clearly. Cheers mbg > > > > > >For internal packages and classes, these will be clearly > marked and > > >we can change them from release to release. Of course, if > we find a > > >wide spread use of an internal API, we may be force to not > change it > > >also. This is basically community promotion of an > internal API to an > > >external API. > > >
