Add first netty 4.2.0 alpha

_config/site.yml

@@ -8,6 +8,10 @@ releases:
  date: 28-Sep-2022
  stable: false 
  eol: false
+ - version: 4.2.0.Alpha1
+ date: 12-June-2024
+ stable: false
+ eol: false
  - version: 4.1.111.Final
  date: 11-June-2024
  stable: stable

news/2024-06-12-4-2-0-Alpha1.md

@@ -0,0 +1,68 @@
+---
+layout: news-item
+title: 'Netty 4.2.0.Alpha1 released'
+author: normanmaurer
+---
+
+We are happy to announce the release of the first alpha for the upcoming netty version 4.2.0. Everyone using netty 4.1.x should be able to upgrade to 4.2.0.Alpha1 without any API breakage. The only new requirement is JDK8 or later. This release has all the fixes that are also included in `4.1.111.Final`.
+
+We encourage users of netty 4.1.x to try out this alpha release and so provide feedback if any breakage is noticed. This will help us to be aware of any problems early in the release cycle. That said, be aware that this is only an alpha release and so __shouldn't__ be considered for production usage.
+
+Netty 4.2.0 will come with some exciting new features, two of which are already included in this first alpha release:
+
+* New way how `EventLoopGroup`s are constructed (the old way is still preserved but marked as `@deprecated`)
+* io_uring based transport
+
+For more details please visit our [bug tracker](https:/netty/netty/milestone/291?closed=1)
+
+
+## New Features
+
+### EventLoopGroup changes
+In previous versions of netty the `EventLoopGroup` implementation was tightly coupled to the respective `Channel` implementation. This made it very hard to extend existing `EventLoopGroup`s to add funcionality like instruments (especially because you might want to use different transports based on the platform you are running on).
+
+This has changed in 4.2.0, here you will use one `EventLoopGroup` implementation for all transports. This allows for easier customization of it (think of it like `ThreadPoolExecutor` that can be extended and customized). To make this possible we extracted the whole IO handling / multiplexing to another class that is injected into the `MultiThreadIoEventLoopGroup`. 
+
+For example:
+```
+new EpollEventLoop();
+```
+
+becomes
+```
+new MultiThreadIoEventLoopGroup(EpollIoHandler.newFactory();
+
+```
+Other transports follow the same pattern.
+
+`MultiThreadIoEventLoopGroup` and `SingleThreadIoEventLoop` provide various methods that can be overridden by the user and so provide the ability to:
+
+* get a count of registered channels / handles
+* understand how long the io processing vs task processing took
+* how many channels / handles were processed per loop run
+* customize / decorate promises
+
+Furthermore, it is now possible to register other things than `Channel`s, which provides a lot of possibilites to re-use netty components and also add support for other `IoHandle` implementations which does not exists as of today. For example, this could be used to implement `file IO` with `io_uring`.
+
+### io_uring support
+This release contains io_uring support for its transports based on our incubator version with changes related to the above mentioned `EventLoopGroup` changes. 
+
+Once 4.2.0 is considered stable we plan to stop mantaining the incubator version of io_uring and so only provide it for 4.2.x in the future.
+
+# Thank You
+
+Every idea and bug-report counts, and so we thought it is worth mentioning those who helped in this area.
+
+Please report an unintended omission.
+
+* [@bryce-anderson](https:/bryce-anderson)
+* [@chrisvest](https:/chrisvest)
+* [@franz1981](https:/franz1981)
+* [@He-Pin](https:/He-Pin)
+* [@honglh](https:/honglh)
+* [@normanmaurer](https:/normanmaurer)
+* [@shoothzj](https:/shoothzj)
+* [@vietj](https:/vietj)
+* [@violetagg](https:/violetagg)
+* [@yawkat](https:/yawkat)
+