overview
for those who don’t follow the Development topic, @mickeyl, @timdecode, and i have recently uncovered an alarming number of highly dangerous stack corruption bugs in the Swift 5.5 release toolchain.
setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the corresponding thread, i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a “Long-Term Support” (LTS) release in our release cycle, much like Ubuntu has been doing for some time.
what went wrong with Swift 5.5?
to summarize, binaries compiled with the Swift 5.5 toolchain currently suffer from a variety of stack corruption-related undefined-behavior. these issues have affected both MacOS and Linux users, and range from merely disruptive (e.g. users experiencing random crashes) to highly dangerous (e.g. callers silently receiving return values that are different from the values actually returned by the callee).
based on my experiences testing the 5.5 toolchain, i estimate that the average Swift application probably now suffers from dozens of instances of undefined behavior, nearly all of which go unnoticed since the data being corrupted is often “unimportant” (e.g. UTF-8 contents of a string), or gets corrupted to a value that is incorrect, but still considered valid by the application (e.g., an account balance getting set to zero.) this problem is compounded by the fact that many of the bugs are highly chaotic — a code change as minor as moving a print(_:separator:terminator:) call up a line could turn a benign stack-corruption bug malignant, and moreover, these bugs often manifest only in release builds, and not debug builds, or vice-versa. this greatly reduces the chance that developers would notice these bugs before releasing applications to the public.
why we need LTS releases
as @Karl has pointed out, the Swift 5.5 release has exposed some very troubling deficiencies in our development-to-release pipeline, which probably requires a revamp of our testing and verification process. this pitch is not meant to detract or minimize the importance of those efforts.
however, we need to recognize the fact that bugs, including severe bugs, are a fact of life in any sufficiently complex piece of software, like the Swift compiler. beyond shoring up our testing and release procedures, we also need to be looking at how we can better serve safety-critical use cases, which require stronger guarantees about the stability of the toolchains they rely on.
async/await in particular, tends to be used in the sort of real-time applications where a subtle stack-corruption bug could have the potential to inflict significant real-world harm. it is not enough to simply fix the issues at hand, and hope it will never happen again. bugs happen. already, the fact that the 5.5 toolchain made it to a public release, and is still available to download on swift.org, is likely to harm the reputation of the Swift language, and i fear that if we do not prioritize release stability, users will come to view Swift as unreliable.
i feel that it would be beneficial for the Swift project to follow the example of the Ubuntu project, and adopt a sort of tiered-release schedule, where every few regular releases is designated as a “Long-Term Support” release, which would receive critical fixes from the mainline, but nothing significant enough to destabilize the product. i think that this is important and necessary to shore up Swift’s credibility as a safe and secure language. what do you all think?