Yep, GEODE-3473 will make it in -- have been waiting for a good moment when there aren't other items in flight that would need to be rebased.
On Fri, Sep 22, 2017 at 2:31 PM, Dan Smith <dsm...@pivotal.io> wrote: > I found bug GEODE-3473 which was created based on this discussion. I marked > that as requiring a fix for 1.3.0, so we don't ship these protobuf related > internal classes as part of the public API. > > -Dan > > On Sat, Aug 12, 2017 at 9:42 AM, John Blum <jb...@pivotal.io> wrote: > > > 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) > > >
