First off I appreciate the entire community here, I know there is a heap of work that goes into the OSS Swift releases and don't want to discredit that.
However, Swift 5.0.1 was released on April 18th 2019 with a fatal bug in Calendar.current which causes a crash. The only viable work around is to hardcode the calendar (which kinda sucks). This bug is already fixed but waiting for a release.
No other programming language will take nearly 90 days to release a hotfix for a fatal bug like this. It's a bit of a shame, we use Swift on the server and have committed to using it for over two years but we can't use the Swift 5.0 toolchain and the latest release of Xcode yet because this bug is holding back our server side deployments.
I don't feel it's reasonable to expect users to code in workarounds for regressions or manually compile toolchains. If this was a new feature that was bugged I'd be a lot more understanding as it doesn't break any existing code but regressions I would hope are more urgent to be fixed and a stable release published.
How can we improve this? Is there anything the community can do to increase the timeliness of Swift hotfix releases?
Not sure which bug you’re referring to. The OSS release of Swift does indeed have a process for incorporating important hotfixes. But, by the mention of Xcode it sounds like you’re referring to the Apple builds, which are controlled by Apple. Moreover, on Apple platforms, Foundation (which vends Calendar) isn’t open source.
If you share code across platforms you cannot use any version of Xcode that uses the Swift 5.x toolchain has it has incompatible changes that do not compile with the Swift 4.x toolchain (even if you leave the syntax mode as Swift 4.x).
Again I'm just expressing frustration that we're not seeing hot fix releases for major regressions like this, it seems like something else needs to be done to ensure we get more timely hot fixes for regressions or other major bugs.
The bug you refer to is specific to swift-corelibs-foundation; as @johannesweiss notes in the second link you post, the fix will be incorporated into the next minor OSS release. Everyone can open pull requests to cherry pick bug fixes for these monthly releases.
@xwu I'm aware it'll be in the next minor OSS release. My reasoning of this post is I believe it's currently inadequate that minor releases are occurring so slowly, especially when critical fatal regressions are present.
It's been nearly 90 days since Swift 5.0.1 was released, are we to expect minor releases are to be at most every 3 months? What about if a major CVE flaw needs to be patched?
I'm 100% more than happy to pitch in and help out if there's anything I can do to help minor releases get out, but it's getting hard to seriously suggest OSS Swift on Server to others when fatal regressions like this exists for months after a "stable" release"
The next release was scheduled to go out mid-June, but it's obviously been delayed. Since it is an open source effort, you could certainly offer to help the release manager, @kevints, with any outstanding tasks.
Swift's design is premised on the philosophy is that it is safer to trap than to continue execution when an unexpected condition arises. You should therefore expect that many bugs will cause crashes. There have been discussions as to how to limit the impact of this behavior on the server, but overall, if trapping under unexpected conditions is as serious an issue as you describe rather than a feature for your use case, then I think it's fair to consider if Swift is the right tool for the job.
I think that the main concern that @robertjpayne has (correct me if I am wrong) is the lack of a timely release to correct this issue. It is great that the Calendar bug was fixed in a relatively timely manner. However, despite this timely fix, the tempo of the hotfix release cycle has led to the bug persisting for multiple weeks. We, as a community, absolutely can contribute to the monthly releases by cherry-picking bug fixes and creating our own, which is excellent, but the fact that they are monthly releases (which can sometimes even be delayed, as is the case here) means that sometimes important bug fixes can take a very long time to actually make it into a release.
I don't think users of Swift should have to be cherry picking in fixes for regressions to create their own stable releases.
Even if everything went totally to plan and this 5.0.2 release came out in the middle of June that is still 60 days after a fatal crashing regression bug was found, I get that it was WWDC time and that probably complicates the issue.
My biggest concern here is companies (like ours) that go all in on Swift for the server now have to start to think about building our own toolchains to get truly stable versions. This isn't impossible, or even that hard really but it definitely is not going to be nice to tell other people that ask "How is Swift on the server?" that "Oh we have to maintain our own release cycle since the official releases can lag months behind with critical fixes".
Particularly this issue will likely bite the community in a large way when a severe CVE is issued that needs 0-day patching.
I'd like to point out that you really are conflating two different things. The Swift language itself isn't the issue, the issue that you are discussing is a library level thing. Comparing it to other open source projects, like say a Linux distribution (I'll use CentOS for the sake of it being more of an enterprise distribution). Let us assume that there is a bug in libxml2. If libxml2 has fixed the bug but not yet made a release, would you claim that CentOS cannot be taken seriously?
I agree that it would be nice to get builds faster, but the builds themselves are pretty complicated, and not very many people are willing to put in the work that is necessary to restructure the monolith that has been built up over time. I've been working on restructuring the build for a very long time, and I would like to believe that it is better, but it still has a long way to go.
I imagine that if you were to start helping with restructuring the builds to be more independent, reliable, and simpler, it would probably go a long way in enabling quicker release cycles. Mind you, there is still the problem of ensuring that the release is solid, but, one step at a time
At least this is a possibility for you. On Apple's own platforms using custom built toolchains to ship apps is impossible, as the built products don't pass App Store submission. Swift on Linux's (ostensible) 30-day update process is far better than what Apple gives its own paying developers, where we're lucky if anything but extremely major issues are fixed quickly, and more minor (but still noticeable) issues might be fixed once a year. It's truly frustrating sometimes, and the issues continue, even when the fixes are available in the open source toolchains (see SR-10257 for a good example). Apple's reasoning for its Xcode release process eludes me, especially when it seems nearly every other dev tool provider can update more frequently. VS Code ships impressive feature updates every month.
This example proves @robertjpayne's point exactly. CentOS would not be taken seriously if it didn't have a well followed update policy to catch updates to critical packages like libxml2 in a timely manner, while also trying to maintain stability by not shipping breaking changes (e.g. only once CentOS 8 ships will OpenSSL 1.1 be supported, meaning older versions don't have easy TLSv1.3 support). No one would seriously consider CentOS, or any OS, for server use unless such timely updates could be made (and in the case of some commercial enterprise distributions, guaranteed under an SLA). This is also one of the many reasons macOS has essentially zero server penetration.
Additionally, I'm not sure what the continued refactoring of the build process has to do with these releases, unless the build has been entirely broken for this entire time. Swift committed to a 30 day release cadence for Swift on Linux. If it can't meet that commitment (after a single release) due to a lack of contributors, then that needs to be announced and a different commitment made. I'm not familiar with Linux release process, but can non-Apple folks make releases? Perhaps allowing outside release management would help meet the schedule if the Apple people are busy.
Ultimately the distinction between Swift-the-language and Swift-the-installable-package is one without a difference. Since no one can use the language without installing it first, they're intimately connected. No one can use language they can't install and no one wants to use a language that they have to fiddle with to get stable releases. I would suggest taking the concerns of the wider community about these issues more seriously, especially as Swift continues lag behind its contemporaries on Linux.
I disagree entirely with that they are the same. Foundation is not needed to write interesting software. I have done that. It was stated multiple times that it is a separate library that needs to be updated, not the runtime, not the standard library, nor the compiler.
Traditionally, with Linux, the distribution is responsible for providing the updated packages, and the distribution is not actually packaging or distributing them. Now, it makes sense to address this and it is possible to ameliorate this on Ubuntu, but, that does require resources. If someone is willing to host a server, I think that this can be addressed quite easily by providing a third party apt repository which would have packages which can be updated nightly and on a release.
Could you elaborate on the how Swift is lagging behind contemporaries? As a point of comparison, the way rust handles this is by building everything from source - which would be possible to do here and would solve the issue. I'm not trying to belittle concerns from others in the community, I just think that they are sometimes not entirely feasible without having someone working on them and the number of non-Apple people contributing to solving the problems in the lower level portions of the Swift stack is quite low.
Treating Foundation as a library separate from Swift may be true in a philosophical sense, and you may be able to write interesting software without Foundation, but there is an even larger category of software which cannot be written without the only proper standard library for Swift. Not if you want to handle dates, text, or anything else most computer programs need to handle.
Regardless of the philosophical distinction between Swift and Foundation, the fact is that they can't be separated in practice — not if you want people to take Swift seriously.
Never mind strings (which can be done entirely in the Swift stdlib, if you don't need localization) and dates. You can't manipulate files at all without Foundation, or a stand-in library.
I tend to agree with you, and I'd love to see this problem solved with an independent solution. Maybe CoreLibs Foundation could be split up into microframeworks for the various pieces that are independently useful and important (e.g. Data and date/time) which could then depend on -- independent of the monolithic umbrella Foundation framework?
