We have policies in place for versioning [1] and backwards compatibility [2]. How do we identify which API’s need to be controlled?
In many cases we use the *.internal.* package naming format to signal API’s that aren’t subject to backwards compatibility requirements. API’s within these internal packages can change and do change even within minor or patch releases. If a user creates an application that relies on an internal API, it may need to be changed during an upgrade. I’ve noticed that we haven’t been following this convention for some newer changes (such as in geode-protobuf). Should we review and modify the packages names continue using the *.internal.* format? Anthony [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311457 [1] https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
