Swift 5 snapshots make the release branch available for testing
Nightly Swift 5.0 development snapshots are available. Their value is testing the release branch against its compatibility goals while the release process still permits selected corrections.
Testing a compiler's next release needs an identifiable candidate. A moving development branch can contain work outside the intended release, while the final build arrives too late to influence its qualification. Swift 5.0's nightly development snapshots provide a way to examine the release branch before the final toolchain.
Mishal Shah's December 4 announcement confirms that the snapshots are available through Swift's downloads page. The announcement is brief, but it implements an expectation established in the Swift 5.0 release process. That process calls for regular snapshots from the release branch as part of continuous integration.
The distinction between a snapshot and a final release matters here. A nightly build supplies compiler behavior that users can examine now. It does not establish that the final release has met all its goals. Its purpose includes finding evidence that can still change the candidate.
I like Swift's deliberate language model, and I care about the effort required to build with it. A release-branch snapshot is useful when it lets those concerns become specific reports about a particular toolchain. That is more informative than assuming that every property of the current development compiler will define the release.
Source and binary compatibility ask different questions
The release plan's primary goal is ABI stability. It describes the intended result as a stable Swift runtime that operating-system vendors can deploy and executables and libraries can link against. This concerns the contract between compiled components at runtime.
The plan also says Swift 5.0 is not binary compatible with earlier Swift releases. Its intended forward compatibility begins with Swift 5. Source compatibility is a separate expectation. The vast majority of source that builds with the Swift 4.2 compiler should also compile with the Swift 5 compiler.
Those statements can coexist. A source program can rebuild successfully even when an older compiled binary is not interchangeable with the new build. Testing whether source compiles therefore supplies different evidence from testing binary interoperability.
Module stability is also a distinct goal in the plan. Its inclusion in Swift 5.0 depends on readiness, with a subsequent 5.x release explicitly allowed. The availability of Swift 5 snapshots should not be read as proof that this separate item has already landed.
For a package author, these distinctions determine what a compatibility report says. Successful compilation establishes something about that source under the selected compiler and configuration. It does not independently establish the future runtime or module-distribution guarantees described in the release plan.
Swift 3 mode has an explicit endpoint
The plan removes Swift 3 compatibility mode from the Swift 5 compiler. Swift 4.2 is the last release supporting that mode. This is a concrete source-compatibility boundary within the broader expectation that Swift 4.2 source should continue to work.
A project relying on Swift 3 mode therefore faces a different question from a project already compiling in a newer mode. The snapshot can expose that dependency before the final release. Identifying the mode in a report is necessary to make the result interpretable.
This is also why the compiler's version and the language mode should not be collapsed into one label. The release process discusses both a new compiler and the removal of an older compatibility mode. A statement that a project uses Swift needs enough detail to distinguish those cases.
My preference is for compiler reports to retain that context. A failure associated with a removed mode has a different explanation from an unexpected rejection of source covered by the compatibility expectation. The snapshot makes either observation possible, but the report still needs to say what was tested.
A release branch narrows the acceptable changes
The release process describes progressively tighter criteria as Swift 5.0 converges. Language and API changes go through Swift Evolution. Other changes, including diagnostics and bug fixes, are assessed according to risk and impact.
After the final rebranch, selected corrections enter through pull requests accepted by the relevant release manager. The plan asks for an explanation of the change, its scope and its specific release risk. It also asks for testing information and review by code owners.
These requirements explain how snapshot feedback can become useful release work. A reproducible failure identifies the problem, while a targeted correction needs its own assessment of impact and risk. Finding a bug and deciding that a late fix is appropriate are connected decisions with different evidence.
The plan also allows low-risk test changes late in the process when they help qualify the release. That gives regression evidence a role beyond the immediate patch. A test can preserve the behavior that the release is expected to maintain.
The snapshot identifies what is being evaluated
Regular snapshots connect public testing to the candidate branch. They let package authors and compiler users report behavior before the official final builds appear. Their usefulness depends on retaining the selected toolchain's identity and the source and configuration used with it.
As of today's announcement, Swift 5.0 remains under development. The available nightly toolchains make its release branch accessible for examination under the published compatibility goals. Reports from those builds can provide the concrete scope, risk and testing evidence that the release process requires for selected corrections.