geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: []DISCUSS] Using package names to identify public API's
Date Fri, 11 Aug 2017 18:37:05 GMT
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, 2017 at 11:34 AM, Michael William Dodge <mdodge@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 <abaker@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
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message