[Netty 5] Project Structure and Artifacts

[normanmaurer]

ee ​https://gist.github.com/Scottmitch/2ca3950f646c071952b868eb8cad5c56​ for more context in general

In general this includes multiple things which are kind of related:

• Versioning

• We would like to follow SemVer more strictly. The goal is to more
  effectively communicate when changes may be necessary to adapt changes, while also allowing us to break APIs more quickly. This may require breaking up the project into individually versioned components.

• Namespacing

• We would like to propose re-namespacing Netty to avoid ABI compatibility
  issues with 4.x. This strategy will be followed when ever there are API breaking changes. In combination with the versioning changes this also provides more justification for breaking the project into individually versioned components.

• Independently versioned components

• As discussed above we would like to break up Netty into smaller independently versioned artifacts. This will help us evolve the Netty project by reducing the scope of API breaking changes and clarify the support contract of different modules (experimental, internal, not supported by the core team, etc...).

• Continuous SNAPSHOTs and nightly HEAD builds/releases?
• Merge some modules ?

We would like to investigate how we can more strictly follow SemVer versioning, evolve the project without causing ABI compatibility issues, but also keeping the overhead low for Netty developers/users. While we all agreed that we should aim to do this its not clear yet what exactly needs to be done.
What we agreed on so far is that we want to use different name spacing for the next major version of Netty (just as we did between 3.x and 4.x). This will also allow users to use different Netty versions at the same time which is the only way how an upgrade can be done step by step.
Beside this we want to investigate what modules we may be able to merge, but will do so with care to avoid over consolidation of independent modules. We would also like to move some existing code into a community supported or “incubating state” due to its current lack of support. Separation of the project will allow us to clarify the SLA for each module, and promote modules after they are stable and have reliable maintainers.

[kevinoliver]

fwiw i get a 404 for the link above: https://gist.github.com/Scottmitch/2ca3950f646c071952b868eb8cad5c56%E2%80%8B

[trustin]

A few ideas:

• My impression is that we need a switch to a better build tool to make all these proposed changes happen without pain.
• To make independent versioning work, we need to provide a BOM. However, our users may still have hard time figuring out what's going on once version conflict occurs.
  • We'll need a BOM regardless we introduce independent versioning anyway because it's useful.