On Monday, March 24, 2014, Rakesh R <[email protected]> wrote: > 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.
No. We should deprecate this. As it allows sharing resources between clients and applications. That is also the reason I don't like shading. > >> 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:[email protected] <javascript:;>] > Sent: 24 March 2014 08:31 > To: [email protected] <javascript:;> > Cc: [email protected] <javascript:;> > Subject: Re: Upgrade ZK version in BK > > On Thursday, March 20, 2014, Ivan Kelly <[email protected] <javascript:;>> > 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 > > >
