Re: []DISCUSS] Using package names to identify public API's

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 wrote: > I found bug GEODE-3473 which was created based on this discussion. I marked >

Re: []DISCUSS] Using package names to identify public API's

+1 for protobuf being internal as they are not intended to be first class OO citizens you can read more about there here (the same warning exists for all supported languages btw) On Fri, Aug 11, 2017 at 12:34 PM, Michael William

Re: []DISCUSS] Using package names to identify public API's

One nice thing about releasing new code in *internal* packages is that we can always move them out of the *internal* packages at a later date but we cannot move non-deprecated code from external API packages into *internal* packages without worrying about backwards compatibility. On Fri, Aug 11,

Re: []DISCUSS] Using package names to identify public API's

+1 to continue using *internal* to differentiate code from external APIs The alternative would require Geode to be more modular, in which we have the external API in API- or SPI-specific jars and then the "internal" packages go into an implementation jar that needs to be on the classpath during

Re: []DISCUSS] Using package names to identify public API's

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 wrote: > > We have policies in