Apple has detailed the release process for Swift 4, which should become available in the Fall of 2017. The main focus of this release is to provide significant enhancements to the core language and standard library while delivering source compatibility. ABI compatibility, who was originally in the roadmap will be deferred, explains Ted Kremenek, who replaced Chris Lattner as project lead on Apple’s Swift team.
Swift 4 will not be properly source-compatible with Swift 3 due to the sheer number of changes that it includes. Rather, the compiler will, for the first time since Swift was introduced, support a compatibility mode, -swift-version-3 that should be able to compile the vast majority of Swift 3 sources, with the exception of incorrect code that the old compiler accepted due to some bug fixed in Swift 4. The -swift-version-4 mode will instead provide support for all the new features outlined in the roadmap. Importantly, the Swift compiler will be able to link together frameworks and modules compiled in either of the aforementioned modes, provided they are compiled using the same compiler.
Kremenek also stated that ABI stability is deferred from Swift 4 to avoid the risk of declaring the ABI stable before the related fundamentals are correct.
This is how Chris Lattner, original creator of the language, [commented] (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170213/032145.html) on Kremenek’s announcement:
Given where we are in the yearly schedule, I think that this is a pragmatic decision. ABI stability is far more important to Apple than it is to most developers, so I’m happy to see that you’re prioritizing the needs of the community (improved compile time, compiler stability, etc), particularly given the importance of doing the right thing for the long term success of Swift.
Deferring the ABI stability goal does not mean however, that work towards that end has stopped, and Lattner expressed the wish for all ABI stability requirements to be nailed down in the early stage of Swift 5 development. Kremenek will shortly announce an ABI stability dashboard that will display a list of all remaining tasks towards declaring the ABI stable and their status.
Entering Stage two means that the bar for a change to be accepted into the release will be higher. For example, any new syntax/API must be clearly better than the existing syntax, any change affecting source compatibility must have a migration path for existing code, etc. All development will take place in the master branch until the release manager will create a final branch, presumably in early Summer 2017. From that moment on, only select fixes will be accepted into the release.
