Windows build is broken

GitHub Issue

D:\a\swift-url\swift-url\.build\checkouts\swift-system\Sources\System\FileOperations.swift:445:7: error: cannot find 'system_ftruncate' in scope

:neutral_face:

I don't like it when my builds break because swift-system published a release without even testing it. Please never do that again.

Sometimes, despite your best efforts, things don't work. That's life. But when basic stuff - really, completely novice-level, first-day-of-coding best practices are not followed, then I think it is correct to start pointing the finger, dispensing anger and attributing blame. At that point, it's not an accident, it's recklessness.

recklessness
lack of regard for the danger or consequences of one's actions; rashness.

I don't care that a commit was merged without tests passing; that happens all the time. But the reason that we have releases as a separate thing from branches is because there is an enhanced presumption that releases will work. The fact this went the extra step - in to a release - without testing - is mind-blowing :exploding_head:

A junior engineer would be embarrassed by that, let alone a package published under Apple's name and maintained by Apple's staff of professional engineers.

Sorry if this seems harsh, but this is an exceptionally poor situation, and I consider it appropriate that those responsible feel fingers and anger directed towards them. Honestly - I would think twice about a junior engineer who showed this kind of abandon and published releases without testing. It's not good enough.

EDIT: No, I don’t think this is inappropriate or worth flagging. The package maintainers are showing a reckless disregard for those who depend on the Windows release and their feet should be held to the fire about it.

We need to have a talk about why this keeps happening. The priority shouldn’t be to shield people from criticism.

1 Like

i noticed this as well.

on the other hand i’m thankful we even got a 0.1.2 release at all, given that the last one came out in 2021. unfortunately the open source swift-system mostly caters to linux/windows users, which is a small user base, and therefore unlikely to be prioritized.

1 Like

For a long time, the iOS SDK also shipped with a module file that couldn’t even be read by the compiler that shipped with the SDK.

There are serious problems here. Some people seem to be trying to sweep it under the rug, but I think it’s actually worth addressing these problems.

Releasing untested builds in to production is never okay. Can we agree on that?

2 Likes

Agreed.

Shouldn't the issue be fixed by a simple #if !os(Windows) statement?

There was a mistake. Supposedly it was tested, but I was misinformed. I'll try to get a revert published ASAP and make sure this cannot happen again.

This is not helpful.

I am personally prioritizing it after 5.7 settles down.

Who are these "some people"? Claiming ill-intent without details is harmful to discussion.

7 Likes

IMO, this is an extremely counterproductive way to approach things, and I wouldn't want to be part of a community where this is the expected practice—there's a reason blameless postmortems are industry-standard.


I am curious why Windows is not part of the standard checks for swift-system PRs. I myself have broken the Swift build on Windows in the past, before Windows was a standard part of the default CI flow. I think the priority here should be making sure that CI covers Windows if it's considered a critical regression to break the Windows build.

8 Likes

without commenting on the larger discussion, one thing you could do is avoid use of upToNextMajor(_:) in swift-url’s Package.swift.

it may also be helpful to maintain your own fork of important dependencies.

next time, tell them to wait until normal business hours.

customers will demand anything until they get some pushback, that is just how customers are.

1 Like

Nope, not at all what I was saying :-). The concept of truth is not applicable to that quoted prose. I was using the concept of helpful. It is not helpful.

SwiftPM comes with dependency-management features as @taylorswift mentioned. You can also use dependency-management software and practices to help you manage your dependencies.

I understand this issue has had an unfortunate impact on you, but focusing on “accountability” (especially personal accountability) is counterproductive to what is hopefully the common aim: mitigation and prevention of future issues. As @taylorswift notes, there are several measures that individual clients can use towards this end if the practices of the maintainers are not sufficient stability-wise for the client’s use cases.

Anger is a perfectly appropriate emotion to feel regarding a 4 AM page, but these forums aren’t appropriate to use as a place to vent anger.

8 Likes

The problem isn't the time - the problem is that I'm having to fight fires that wouldn't exist if there was even basic testing for Windows. This thing doesn't even build.

And that's why I think "recklessness", even though some may not like the word, perfectly describes this situation. It just seems like nobody even cares -- or why was it evidently not tested by CI?

We need people to care. Hopefully now that there is some outrage, next time it comes to a release, the maintainers think "huh, we should really test this, you know? Last time, we just YOLO'd it, and people got upset when all their builds broke."

Again, the time is not the problem. The customer was completely right and I sympathise with them.

a bit off-topic, but this is a great argument for why you should check in your Package.resolved

3 Likes

Nope, it's not about that at all. I'm saying it isn't helpful to the project and is counter productive to fostering helpful discussion on the forums. I don't know what you're getting out of it, but I genuinely hope that you can find a better way to get it.

I can guarantee you that unhelpful hyperbole and personal attacks do not result in those thoughts arising. It does, however, demonstrate that whatever it is you're getting from this is more important to you than the well being of the project. This is good to know.

5 Likes

OK, well, I think your vague insinuations that I have ulterior motives and "can find a better way to get it" are far more of a personal attack. There's not even an attempt to hide it. If you're looking for unhelpful hyperbole, how about: "whatever it is you're getting from this is more important to you than the well being of the project"?

YOLOing that release broke several production systems, remember? I was just one of many people using the package.

I think you're completely misreading my replies and it doesn't seem like we're making any progress there.

Anyways, the bug was reverted and 1.2.1 was released

Also, it appears Issue #94 has been opened to track some of the work necessary to ensure Windows does not get broken in the future.

2 Likes

Version 1.2.0 of the swift-system package accidentally broke the package on the Windows platform. We’ve released version 1.2.1 to resolve the issue.

We’re implementing process changes to prevent this class of problems from reoccurring in the future.

9 Likes