SwiftPM pitch would allow multiple major package versions

Swift Package Manager has always resolved exactly one version of each uniquely identified package. A pitch on the Swift forums would lift that rule for major versions, letting different majors coexist in one graph so diamond-shaped dependency conflicts stop failing resolution.

bripeticca formalized the proposal after months of investigation and prototype work. Conflicting major-version requirements often appear in transitive dependencies the root package does not control. Current workarounds push the cost onto developers: pin older releases and forgo newer APIs, pressure authors to avoid major bumps, or fork and rename repositories to create a separate package identity.

The pitch would start behind an opt-in flag on resolve, build, run, and related commands. Early feedback challenged that choice. Franz Busch argued large graphs already hit the problem routinely and that other package managers do not require opt-in. Honza Dvorsky agreed the end state should be default behavior, possibly after an initial opt-in period tied to a future tools version. He noted the grpc-swift v1 to v2 migration already showed how painful the gap is for transitive consumers who should not have to know or act when a dependency migrates majors.

C targets were another point of friction. The initial write-up kept today's hard failure when a conflicting package contains C modules. Busch called that too restrictive for server packages that wrap system APIs; those packages already prefix C symbols, so guidance could simply require a distinct prefix per major version. The proposer agreed SwiftPM need not fail outright and can instead surface the prefixing expectation.

Other reviewers flagged practical risks: multiple library copies in one binary can produce surprising runtime behavior, such as duplicate embedded servers competing for the same port. One suggestion was a package-manifest clause, similar to module aliasing, that lets a root package explicitly allow multi-major resolution for named transitive dependencies. Further comments looked ahead to isolated dependency subtrees and clearer package-identity replacement once majors can coexist.

The feature would initially focus on Swift modules. Discussion leans toward treating multi-major resolution as normal ecosystem behavior rather than an exceptional opt-in as packages continue to ship new majors.