/cc @trustin @nmittler @Scottmitch @ejona86 @louiscryan

Also I should have mentioned that we should create a new branch from current master that we keep for "backup" reasons. So we can port code if the need arise later.

+1. I'd like to keep the handler type hierarchy simplification for later cherry-pick (?) though.

A few questions:

• So what do you propose creating exactly, for example where would these changes (deprecating exceptionCaught, exposing EventExecutorChooser, etc.) be applied - 4.1, 4.2, or a new 5.0 branch?
• If I remember correctly, 5.0 merged ChannelInboundHandler and ChannelOutboundHandler as well as introducing messageReceived as a replacement for channelRead0. What would happen to these changes?
• Will all features/improvements currently applied to master be ported to this new release? Obviously HTTP/2 was ported to 4.1, just wondering if there is anything else sitting on master that would need attention.

That's a bit sad but I would support this change D: wasn't the major feature of 5.0 fixed eventloop migrations or something like that?

So what do you propose creating exactly, for example where would these changes (deprecating exceptionCaught, exposing EventExecutorChooser, etc.) be applied - 4.1, 4.2, or a new 5.0 branch?

@blucas - Unless there are objections I think the proposal is to apply these changes to 4.1. The discussion revolves around there not being enough API changes/core features to justify maintaining a different fork. Any deprecated methods/interfaces would also be marked accordingly in 4.0.

If I remember correctly, 5.0 merged ChannelInboundHandler and ChannelOutboundHandler as well as introducing messageReceived as a replacement for channelRead0. What would happen to these changes?

Are you thinking of 4.1 SimpleChannelInboundHandler.channelRead0 vs 5.0 SimpleChannelInboundHandler.messageReceived? In 4.1 I guess we would keep channelRead0 to stay API compatible with 4.0

Will all features/improvements currently applied to master be ported to this new release? Obviously HTTP/2 was ported to 4.1, just wondering if there is anything else sitting on master that would need attention.

That is the intention. If you know of any please call them out :) We will rename the "master" branch so nothing will be lost if we forget/miss something.

@blucas what @Scottmitch said.

@ninja- event loop migration works in 4.0 as well.

@normanmaurer - Also as a reminder we should revisit deprecated items in 4.1. If things have been deprecated in 4.1 in favor of a change in 5.0, we may want to un-deprecate these items.

@normanmaurer - For example AUTO_CLOSE channel option may be a candidate.

Meanwhile, let me change the default branch from 'master' to '4.1'.

Thanks! Will take care of the rest once back from vacation

Am 06.12.2015 um 07:02 schrieb Trustin Lee notifications@github.com:

Meanwhile, let me change the default branch from 'master' to '4.1'.

—
Reply to this email directly or view it on GitHub.

As Netty In Action covers 4.x,I think this should be fine.

master branch was rename to master_deprecated. Changes only need to go to 4.0 and 4.1 now.

Woot! thanks @normanmaurer!

For existing 5.x user, do you recommend to change back to use 4.x or I can still use 5.x? What's the recommend way now

Use 4.0 or 4.1

Am 09.03.2016 um 20:37 schrieb junchaowu notifications@github.com:

For existing 5.x user, do you recommend to change back to use 4.x or I can still use 5.x? What's the recommend way now

—
Reply to this email directly or view it on GitHub.

@normanmaurer this change will break TChannel-JAVA and all TChannel-JAVA users.

@ShanniLi again just use netty 4.0 which works on android

@ShanniLi 5.0 was alpha so you should expect breakage.

@normanmaurer @trustin:
My major concern is that in 4.X, when implement a UDP server, there is only one channel and Eventloop to handle all the IO operation by design(as far as i understand). This would definitely introduce a performance issue when many devices are try to connect to the server at the same time. And unfortunately, we cannot utilize the Linux epoll as the kernel version is only 2.6. Is there any workaround available in 4.X? Please let me know.

Many Many Thanks!

Kan

Mark and support

come on , waiting for next time updated

mark

ok

https://github.com/netty/netty/projects/1

netty demo for 4.1
https://bugstack.cn/index.php/category/netty%E4%B8%93%E9%A2%98/

mark

netty demo for 4.1
https://bugstack.cn/index.php/category/netty%E4%B8%93%E9%A2%98/

https://bugstack.cn/itstack-demo-netty/itstack-demo-netty.html
链接也更新一下呐

mark

What direction will netty 5.x consider to improve performance?
Will you consider the follow-up Java cooperation program (Virtual Thread) ?