On the flip side of internal vs. external APIs, I definitely feel there are many classes under "*.internal" packages that should be reviewed and made public. I realize it increases the surface area of maintainability and support for backwards compatibility, but anytime an application needs access to the functionality the "internal" API provides, those are good candidates. Keep in mind that there is a huge disparity between the public API and cache.xml at the moment and applications coded to the API (rather than XML) are going to suffer.
On Fri, Aug 11, 2017 at 11:46 AM, Ernest Burghardt <eburgha...@pivotal.io> wrote: > +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 > > > > > > > > -- -John john.blum10101 (skype)
