Plan for NIO 2 and Swift 5

(Helge Heß) #3

Too be honest - unless there are more radical API changes - I'd prefer to keep the version and #if swift(>=) the Swift 5 changes. Yes, this is a little ugly sometimes, but not that much (especially if you place the different versions in different files/compat directories).

I'm aware that this is probably not a very popular opinion though :slight_smile:

(Tanner) #4

Great news! Vapor should follow suit soon after SwiftNIO with development on the next major version.

Will you be tagging pre-releases (i.e., 2.0.0-alpha.1), or will we need to depend on .branch("master")?

1 Like
(Daniel Dunbar) #5

We are on board with this plan, thanks for the update @johannesweiss

1 Like
(Johannes Weiss) #6

The #ifs aren't powerful enough for that. For example to conditionally add an attribute (like @inlinable) you'd need to copy the whole function body and everything it calls. Then it'd basically become two code bases in one repo which becomes unmaintainable. Also we want to delete deprecated stuff and make use of new features in Package.swift etc.

1 Like
(Johannes Weiss) #7

At the very beginning I'd probably recommend to depend on master, then in later stages I'd be open to have pre-releases. We very much would like input from our community here.

(Ankit Aggarwal) #8

If you're going to require Swift 5 for NIO, can you also update the Package manifest to use the latest tools version? At the very least, it will allow you to drop the zlib and openssl support dependencies.

(Johannes Weiss) #9

Yes, we'll be // swift-tools-version: 5.0 from day 1 and we'll be super happy to drop the support packages :slight_smile:

4 Likes
(Tanner) #10

We had some trouble using tip of branch dependencies during Vapor 3's development. IIRC, there are some features of SPM that become unavailable. That might not be a problem anymore with Swift 5's SPM though, so I think we can address tagging pre-releases if/when it becomes an issue.

(Johannes Weiss) #11

paging @Aciid

(Ankit Aggarwal) #12

The limitation is that all branch-based dependencies should be reached via other branch-based dependencies.

Not allowed:

A depends on B @ 1.0.0
B depends on NIO @ master

Allowed:

A depends on B @ develop
B depends on NIO @ master

This limitation can be worked around but packages with branch-based dependencies shouldn’t publish releases in the first place. The workaround is:

A depends on B @ 1.0.0
A depends on NIO @ master
B depends on NIO @ master

2 Likes
(Jon Shier) #13

What's the plan for Xcode support? Will certain commits be synced to certain toolchain builds, or will you just work off the latest? Who knows what Apple's Xcode release plan is for Swift 5, but I wouldn't expect a version with official support until the official Swift 5 release in the spring.

Also, I should get my logging PR up at some point.

(Johannes Weiss) #14

I think the plan right now is to work from the latest 'Swift 5.0 Development' toolchains that will (hopefully) be available on swift.org/download as soon as the swift-5.0-branch will be cut.
Time will tell how stable those toolchains will be and if we need to maintain some form of guidance on what exact toolchain to use. I'd say let's deal with this issue when it becomes one. The extra benefit of working with the latest snapshots is that we can give early feedback to the Swift compiler developers.

In Xcode you'd need to have whatever is the latest and then select the custom toolchain in Xcode -> Toolchains.

(Jon Shier) #15

That's about what I expected. I just wish there was a way to have a project open with a toolchain automatically, like you can with rustup.

1 Like
(Johannes Weiss) #16

That would make a great SwiftPM proposal I think. Maybe it could even advise Xcode (through the generated xcodeproj) what toolchain to use?

(Jon Shier) #17

I think that last part is the issue: Xcode has no way of setting a toolchain on per project level, AFAIK. That would require integration on Xcode's side for SPM to take advantage. I'm not sure how SPM support would work on its own, as SPM is part of the toolchain.

(Johannes Weiss) #18

paging @Aciid again :slight_smile:

(Ankit Aggarwal) #19

You can add a user-defined build settings at the project level with the settings name "TOOLCHAINS". The value should be the bundle identifier (can be obtained from Info.plist) of an installed toolchain.

4 Likes
(Johannes Weiss) #20

We have released SwiftNIO 1.12.0 which in all likelihood will be the last minor release in the NIO 1 series. It's well possible that there'll be NIO 1.12.x releases for bug fixes.
Immediate consequences:

  • master will become Swift 5-only any time now (probably tonight)
  • later today we should get CI (including PRs) for the nio-1.12 train branch
2 Likes
(Johannes Weiss) #21

This post is only relevant to library developers who want to depend on NIO’s master branch before the first NIO 2 versions get tagged.

If you’re a user of a library that uses SwiftNIO or the author of a library and you depend on NIO using tagged versions (from: “1.0.0” or similar) you don’t need to worry at all.

For all the packages that track NIO’s master whilst NIO 2 is developed just a small piece of information: we added a module called _NIO1APIShims to NIO’s master branch. Until NIO 2’s API stabilises we’ll keep that module around and will continue to shim NIO 1’s API to make it easier for our users to port their code over to NIO 2.

So if you don’t want to wait for the NIO 2 release and want to track our master branch whilst NIO 2 is taking shape, I’d recommend that where ever you import any NIO modules you’ll also import _NIO1APIShims. That way you get warnings with nice fixits in Xcode rather than compilation errors. But even after fixing those warnings, I’d recommend keeping the import of _NIO1APIShims in just so that we don’t break you again the next day.

As promised we also keep a list of all public API changes we have done: https://github.com/apple/swift-nio/blob/master/docs/public-api-changes-NIO1-to-NIO2.md

I should add that for NIO 2 development you will need a recent Swift 5 snapshot and you’ll need to patch your Xcode to make it properly work with Swift 5 until: How to set Swift version 5 (for recent dev snapshots) in Xcode build settings? . That is only until an Xcode that officially supports Swift 5 comes out of course.

If there’s any questions or suggestions, please let us know. Thank you!

2 Likes
(Johannes Weiss) #22

Just two minor announcements here:

  • with the 10.2 beta, you no longer need to patch your Xcode (but you'll still need a very recent Swift 5.0 development snapshot toolchain from swift.org)
  • we initially thought 1.12.x would be the last NIO 1 minor version, turns out we needed a 1.13.0 but that shouldn't affect anybody.
2 Likes