+1 for protobuf being internal as they are not intended to be first class OO citizens you can read more about there here <https://developers.google.com/protocol-buffers/docs/javatutorial> (the same warning exists for all supported languages btw)
On Fri, Aug 11, 2017 at 12:34 PM, Michael William Dodge <mdo...@pivotal.io> wrote: > 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. > > Sarge > > > On 11 Aug, 2017, at 11:30, Anthony Baker <aba...@pivotal.io> wrote: > > > > 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 > > > >
