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

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