bookkeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakesh R <rake...@huawei.com>
Subject RE: Upgrade ZK version in BK
Date Mon, 24 Mar 2014 12:54:08 GMT
Thanks everyone for the reply.

>> We do use ClientSocketChannelFactory.
Would it be possible to deprecate this usage ? Anyway this would be handled gracefully when
we shade netty library in future.

>> As I said before, we are close to 4.3.0, let's not bump any version at last minute,
unless there is critical bugs need to fix.
>> We could bump zk and Netty versions in next release.

Thats fine.

-Rakesh

-----Original Message-----
From: Sijie Guo [mailto:guosijie@gmail.com] 
Sent: 24 March 2014 08:31
To: bookkeeper-dev@zookeeper.apache.org
Cc: bookkeeper-user@zookeeper.apache.org
Subject: Re: Upgrade ZK version in BK

On Thursday, March 20, 2014, Ivan Kelly <ivank@apache.org> wrote:

> My take on this is actually that we should shade this also.
>
> [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we 
> force anyone using bookkeeper to upgrade also. As [1] says, the 
> changes may not be binary compatible. I've actually experienced this 
> problem with netty recently, though I think it was between major 
> versions. In any case though, if binary incompatible can happen, we 
> shouldn't break anyone by having them use us.
>
> However, shading would involve a source compat break for us, as one of 
> the constructors for BookKeeper takes a ClientSocketChannelFactory. My 
> vote on this, is to break this constructor for 3.4.0 release, upgrade 
> netty and shade it. I really doubt anyone is using the constructor 
> with ClientSocketChannelFactory.


We do use ClientSocketChannelFactory.



> Also, for 3.4.0, we should split out
> the client package into a separate module to avoid pulling in too many 
> modules. It's not a huge amount of work. I think I did it in 45 
> minutes before, but it needs to be done when there's very little 
> outstanding work, and files move around a lot.
>
> Sijie, what do you think? You've been opposed to shading in the past.


As I said before, we are close to 4.3.0, let's not bump any version at last minute, unless
there is critical bugs need to fix.
We could bump zk and Netty versions in next release.


>
> -Ivan
>
>
>
> > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> While bumping the version to ZK-3.4.6, I've noticed one small diff 
> about the netty versions.
> >
> > ZK has netty version - 3.7.0
> > BK has netty version - 3.2.9
> >
> > As part of ZOOKEEPER-1715, it has upgraded the netty version to 
> > 3.7.0 <dependency org="io.netty" name="netty" conf="default" 
> > rev="3.7.0.Final">
> >
> > But in BK we have different version 3.2.9
> >     <dependency>
> >       <groupId>org.jboss.netty</groupId>
> >       <artifactId>netty</artifactId>
> >       <version>3.2.9.Final</version>
> >       <scope>compile</scope>
> >     </dependency>
> >
> >
> > Following are few ideas that comes in my mind, which I'm putting to 
> > kick
> start the discussion.
> >
> > Approach-1) Since BK is not using ZooKeeper's netty feature, it can 
> > simply exclude the netty library while adding ZK-3.4.6 dependency 
> > and BK will continue using his own version.
> BK uses the zk client which does use netty.
>
> > Approach-2) BK also will upgrade its netty version to '3.7.0' and be 
> > in sync with ZK-3.4.6. Here it would need to see old - new BK 
> > communications.
>
> >
> > Appreciate any help in finding a better way. Also welcome fresh 
> > ideas:)
> >
> > Thanks & Regards,
> > Rakesh R
> >
> [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>

Mime
View raw message