SSWG Meeting notes: January 29th 2025

Server Workgroup Updates
1

Attended: @Joannis_Orlandos @ktoso @taylorswift @tachyonics @tiborbodecs @adam-fowler @0xTim

Carry over action items

New action items

  • :a: Form a strategy which SSWG maintained projects could move to swiftlang org
  • :a: Follow up about if macro build time issues are already in 6.1 @FranzBusch @tachyonics

Today's topics

Evolution process for SSWG maintained libraries (e.g. swift-server)

  • Bunch of repos moved to swiftlang
    • Core team is debating what should go there
  • Some folks argue swift-log should go into swiftlang
  • When going to Swiftlang we should decide who owns the repository in the repository
    • Swiftlang org is "not apple"; Unified evolution process from contributor experience group

Ecosystem steering group

  • Which projects need to be steered by this group?

  • Which projects need to be part of swiftlang and do we run an evolution process?

  • TIbor: Big question: What is purpose of swiftlang repository?

  • Joannis: Swift nio is essential building block on non apple platforms

  • Adam: Should NIO be treated as the same level as Log, Metrics, Tracing

    • NIO is under Apple org; is for server but it is not platform agnostic.

  • NIO is an implementation detail, and should not show up in API library.

  • We think the API packages should be in swiftlang because they are not platform dependent but implementations should be OUTSIDE of swiftlang. E.g. swift specific platform backend.

  • Logging and tracing etc are just APIs, and there must be more implementations of their backends.

  • We do not want to bring HTTP Client to swiftlang because it is not the "ONLY" on all platforms one.

    • It would be misleading to put it into swiftlang.

  • Potential question to core team: workgroups have their own organizations.

    • this could mean swift-server being less "odd"

  • Idea: We should run evolution for our core packages

  • :a: Keep working on messaging about our which libs go into swiftlang.

    • We would like swift-server the workgroup for SSWG server projects.
    • We argue that the we do evolution only for the 4 packages that are APIs

  • Followup question: Is there an org for "swift ecosystem"?

Swift testing and support for last three versions of swift.

  • Vapor's JWT Kit now requires Swift 6 because it uses Swift testing
    • Bumped tools version to Swift 6
    • So this breaks the "three versions backwards support"
  • Franz: Keep tools version at 5.8 and not run tests on older versions
    • Bumping the tools version allows you to support
    • NIO won't require swift-testing and 6.0 and break support for older versions -- we're keeping the promise to support a few versions back
  • New libraries will do everything with swift-testing
  • New major versions can just support the latest version
  • Konrad: Maybe the scale is more gray than black and white; and the 3-versions-back does not necessarily apply to all, even incubated ones, equally?
  • Franz: Thinking about how mixing versions of projects in the same build could be the future here; especially to protect from "nio 3" IF it ever happens. But that's still far far out and we should not count on such feature existing in SwiftPM anytime soon.

Any word on a public artefact repository? Is there anything we can do to help?

  • Simon: Working with other ecosystems...
  • Tuist just set up a registry actually.
  • Adam was building a registry for fun; works pretty well.
  • Security and ops is very difficult
  • Registry is about supply chain security.
  • Index is the discoverability.
  • Sven: Packages or prebuilt libraries...?
    • Simon: at the very basic level just packages.

Current status of macros

  • Is there still a concern about swift macros?
  • Tim: Should be solved in 6.1
    • The caching has been solved; prebuilt artifacts shipping with toolchain.
    • Is the dependency problem solved?
  • Franz, Simon: follow up about if this is solved already in 6.1
10 Likes