tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: What's our policy for Thrift changes?
Date Thu, 20 Oct 2016 16:35:43 GMT
Hi Andreas,
I don't think semantic versioning slows down development. It's just a
convention so that your consumers know more of what to expect. Were you
thinking of letting consumers know in some other way when wire
compatibility breaks? Just release note it (easy to miss)? Or just not
letting them know at all (scary for consumers)?

IMHO, only keeping wire compatibility for two consecutive versions is too
short. I can see that some bigger changes might cause a burden on
development, but what's the harm in this particular case of leaving the old
method around longer? If it's a bigger change, you might consider it a new
major release, though, in which case breaking compatibility is acceptable.
But the downside is that your consumers may not upgrade in that case.

Cheers,
James

On Wed, Oct 19, 2016 at 6:40 PM, Andreas Neumann <anew@apache.org> wrote:

> Hi James,
>
> I am not sure how soon Tephra can establish semantic versioning. That
> typically happens after a podling graduates from the incubator, and Tephra
> has not had a 1.0 release yet.
>
> In the mean time, I agree that we should try to preserve the compatibility
> with older clients, but I would not want that to slow down new development.
> Would it be sufficient if we keep compatibility between two consecutive
> releases?
>
> For now, please take a look at
> https://github.com/apache/incubator-tephra/pull/18 where I implemented the
> "new method approach".
>
> Cheers -Andreas
>
> On Wed, Oct 19, 2016 at 12:09 PM, James Taylor <jamestaylor@apache.org>
> wrote:
>
> > I meant that Phoenix can't pick up new Tephra releases that break wire
> > compatibility until Phoenix has a major release.
> >
> > I'd vote for the new method approach with the old method being
> deprecated.
> >
> > When you can remove deprecated methods is always tricky. IMHO, it'd be
> > great for Tephra to establish semantic versioning like Phoenix & HBase so
> > that it's clear if/when wire compatibility may break (i.e. on major
> > releases) and/or deprecated methods are removed.
> >
> > Different projects follow different schemes, though. From the Guava
> > approach of removing deprecated methods often (and the nightmare that
> > creates for consumers IMHO) versus the HBase approach (which works pretty
> > well IMHO).
> >
> > Thanks,
> > James
> >
> > On Wed, Oct 19, 2016 at 11:43 AM, Andreas Neumann <anew@apache.org>
> wrote:
> >
> > > Hi James,
> > >
> > > I assume you are talking about a major release of Phoenix. We do have
> to
> > > anticipate that improvements and new features in Tephra will require
> > Thrift
> > > changes. So what would be the process to coordinate that?
> > > - Does it mean that Tephra cannot make changes unless a major Phoenix
> > > release is expected?
> > > - Or does it mean Phoenix will not pick up new Tephra releases until it
> > has
> > > a major release?
> > >
> > > For TEPHRA-194, we can introduce a new method - say
> > startShortWithTimeout()
> > > - that throws the new exception, and change the
> TransactionServiceClient
> > to
> > > use that new method. Old clients will call the old method
> > > startShortTimeout() and still work, but they won't get the improved
> > > exception handling.
> > >
> > > The question then is how long do we have to wait before we can remove
> the
> > > old method?
> > >
> > > Thanks -Andreas
> > >
> > >
> > >
> > > On Mon, Oct 17, 2016 at 8:44 PM, James Taylor <jamestaylor@apache.org>
> > > wrote:
> > >
> > > > Hi Andreas,
> > > > Phoenix can't assume that the client and server are the same version
> as
> > > we
> > > > support rolling upgrades for patch and minor upgrades. It'd only be
> ok
> > > for
> > > > a major release.
> > > > Thanks,
> > > > James
> > > >
> > > > On Monday, October 17, 2016, Andreas Neumann <anew@apache.org>
> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > As part of https://issues.apache.org/jira/browse/TEPHRA-194, it
> > would
> > > > make
> > > > > sense to introduce a new exception type in the thrift module. That
> > may
> > > > > break wire compatibility with previous versions.
> > > > >
> > > > > I am wondering what the current policy is for changing the Thrift
> > > > > protocol?Can we safely assume that - for now - the server and
> client
> > > will
> > > > > always be the same version of Tephra?
> > > > >
> > > > > Cheers -Andreas
> > > > >
> > > >
> > >
> >
>

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