My preference would be to use semantic versioning. Since the upgrade to Netty 4.1 is a breaking change, that would make the new version 2.0.x.
The problem with matching the Netty version numbers is that the lifecycle of the project may not match Netty - perhaps after adding and releasing HTTP2 support we find that our approach was wrong and we need to change the API, then we'd have to do a breaking change in a point version of 4.1.x. Of course, there's always a risk that we'll need to do a breaking change to the 4.0 version, and that will have to be a 1.1.x, but the chance of that happening I think is much lower than the chance of a breaking change happening on the current active development branch.