Motivation:
With NIO 2.32.0 we broke the core NIO module up into modules that split
apart the POSIX layer and the core abstractions. As a result, this
package no longer needs to express a hard dependency on the POSIX layer.
Modifications:
- Rewrote imports of NIO to NIOCore.
- Added NIOEmbedded imports where necessary in tests.
- Note that the main package still _depends_ on NIO, which is necessary
for backwards-compatibility reasons. This dependency is unused.
Result:
No need to use NIOPosix.
Motivation:
In NIO 2.9.0 we moved all first-party `ChannelOption` types into their
own namespace. That was a good idea, but NIOTS uses them too and so it
now encounters build warnings. Additionally, NIOTS defines its own
`ChannelOption`s, and so should namespace those as well.
Modifications:
- Updated the code to use the namespaced `ChannelOption` types.
- Namespaced our own.
Result:
More namespacing.
Motivation:
With Network.framework becoming available on watchOS, you should now be
able to run your favourite NIO applications on watchOS 6!
Modifications:
Updated availability annotations to allow NIO TS.
Result:
More NIO on more watches
* Annotate code with availability attributes
Motivation:
It was not possible to import NIOTS into a project where
Network.framework was not supported by all deployment targets.
Modifications:
All NIOTS code, where applicable, was annotated with availability
attributes.
Result:
It is possible for application developers to import NIOTS on platforms
which do not support Network.framework without a compile time error.
Motivation:
NIOTS will not work on Linux but we can at least make it not fail
compilation when compiled on Linux. That way consumers of the API can
depend on NIOTS but make sure they only use NIOTS when wrapped in a
`#if canImport(Network)` block.
Modification:
Guard everything by `#if canImport(Network)`
Result:
This package will now build on Linux (without providing any useful
code).
Cory Benfield
Johannes Weiss
George Barnett