Mailing-List: contact dev-help@tephra.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tephra.incubator.apache.org
MIME-Version: 1.0
Sender: neunand@gmail.com
In-Reply-To: <CAAF1Jdho0dy9E0JycRVEbzLLS4QKq+dPsqPULkrVarJgguxSEA@mail.gmail.com>
References: <CANpmDOdOYEAmWc8QHbV2qU4ue=xSr1cC8yCtVGu8wQ7KyvnEKQ@mail.gmail.com>
 <CAAF1JdjEEA2y5XXs0xHjhp5Juyre5u-ShoeQQst0KLY6vJ_MPQ@mail.gmail.com>
 <CANpmDOcbzM+8c3WNohV_06QuBMVrgY2=C7QXNhMeoRQScnNNmw@mail.gmail.com>
 <CAAF1Jdg5HOp2xAAGmvPiGdubw5gYq1mEp=B4Dfyc7a4oP=emBQ@mail.gmail.com>
 <CANpmDOf_96Vtj__O0y8=-cbkRL9L6n1GqBiA+JyvD6FzrkC62A@mail.gmail.com> <CAAF1Jdho0dy9E0JycRVEbzLLS4QKq+dPsqPULkrVarJgguxSEA@mail.gmail.com>
From: Andreas Neumann <anew@apache.org>
Date: Tue, 17 Jan 2017 20:07:18 -0800
Message-ID: <CANpmDOcsru0xmLruGFSkshyCdzC5BaskDdFYrtW5_KTFFAE+8w@mail.gmail.com>
Subject: Re: What's our policy for Thrift changes?
To: dev@tephra.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a114697b0818ea30546568d6d
archived-at: Wed, 18 Jan 2017 04:07:41 -0000

--001a114697b0818ea30546568d6d
Content-Type: text/plain; charset=UTF-8

Hi James,

sorry for dropping the ball on this. For the specific Jira I was working
on, I kept the old interface and introduced a new one that exposes more
functionality. I agree that this should be standard practice.

I opened https://issues.apache.org/jira/browse/TEPHRA-211 where we can
discuss semantic versioning.

Cheers -Andreas

On Thu, Oct 20, 2016 at 9:35 AM, James Taylor <jamestaylor@apache.org>
wrote:

> 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

--001a114697b0818ea30546568d6d--