The user shouldn't need to access any of the protobuf classes directly. I'm in
favor of making all of the protobuf-related packages internal, including any
classes generated from .proto files.
> On 11 Aug, 2017, at 11:30, Anthony Baker <aba...@pivotal.io> wrote:
> We have policies in place for versioning  and backwards compatibility .
> 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?
>  https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311457