Enable 6.2 CI and enable Windows CI

[FranzBusch]

No description provided.

[czechboy0]

Should we instead compile out these unix signals on Windows for now completely, so even the ServiceGroup doesn't have those parameters in its initializers? We can later add support for the Windows-specific termination handling using the right terminology, and add more initializers then.

[FranzBusch]

In my opinion, no. I intentionally didn't compile them out because that makes writing cross platform Swift apps with ServiceLifecycle really hard to maintain since users now need to #if os(Windows). IMO, the best place forward is to define event handlers here a well and add an event handler parameter to the ServiceGroup but that can be done in a follow up PR.

[czechboy0]

Once we make this build on Windows, "UnixSignal" becomes API on Windows. I don't love that and would prefer we compile it out and only deliberately add a potential Windows-specific or a cross-platform API (called e.g. "service event") that uses the right platform-specific API under the hood. But landing this is a one-way door we can't remove for the rest of ServiceLifecycle 2.x, and we don't really benefit from it.

I think it's fine for those writing cross-platform services to handle this in their app for now, and we can introduce a cross-platform event API later.

[FranzBusch]

Again I disagree. Forcing users to write conditional code based on platform is a horrible pattern. I think it is totally fine for UnixSignal to be an API on Windows that just isn't doing anything with it being documented. Packages that have different surface API based on platform is a huge pain that we often encounter ourselves e.g. Foundation vs FoundationEssentials.

For a low-level library like swift-system that might be fine but for a higher level library like ServiceLifecycle I think we should strive to keep the APIs aligned across platforms.

[czechboy0]

So what's the plan when event handling is supported on Windows in Service Lifecycle? What will that look like in the ServiceGroup initializer?

[FranzBusch]

We just expand the API. We have two possibilities:

1. Adding a new WindowsConsoleEvent struct and two new properties to the group configuration i.e. gracefulShutdownConsoleEvents and cancellationConsoleEvents.
2. Trying to come up with a cross platform representation like TerminationEvent that covers both unix signals and console events.

I am currently thinking that the former, is the better way forward since I think it is pretty hard to come up with a cross platform representation. swift-subprocess is doing something similar.

[czechboy0]

Would WindowsConsoleEvent be a symbol that's present on macOS and Linux?

[simonjbeaumont]

Have you considered moving unix signals behind a trait. Trait would be default enabled on all platforms where Swift Service Lifecycle currently builds. Could default to disabled on Windows? Could possibly even annotate them as unavailable?

[FranzBusch]

Would WindowsConsoleEvent be a symbol that's present on macOS and Linux?

Yes. Same argument applies the other way around. Somebody wanting to write a cross platform service that uses ServiceGroup should not be forced to write #if os() code.

Trait would be default enabled on all platforms where Swift Service Lifecycle currently builds.

Traits cannot be enabled based on platform. They are orthogonal concepts.

[czechboy0]

Yes. Same argument applies the other way around. Somebody wanting to write a cross platform service that uses ServiceGroup should not be forced to write #if os() code.

Fair enough, while I don't agree with the tradeoff here, it is a reasonable position and I'll defer to you here.