+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 runtime.

On Fri, Aug 11, 2017 at 11:30 AM, 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

Reply via email to