Preparing for Swift Algorithms v1.0

Hi all,

We're planning to tag version 1.0 of Swift Algorithms within the next few weeks. If there's anything about the algorithms currently provided by the package that you'd like to see changed, now is the time to let us know. After the release of v1.0, source-breaking changes will only be considered for major version bumps in accordance with Semantic Versioning.

The biggest planned change between v0.2.1 and v1.0 is the renaming of most sequence and collection types to include a *Sequence or *Collection suffix for consistency with the standard library. One such example is the renaming of the Uniqued type to UniquedSequence. The release/1.0 branch, from which v1.0 will be tagged, already has these changes applied. New algorithms that are close to landing on main will be included in a subsequent minor release.


Hey Tim,
A small question is if we should consider removing deprecated APIs such as those swift-algorithms/Rotate.swift at bf00df1fd2f6db6aae5773905b16e5742f44dbe8 · apple/swift-algorithms · GitHub on the first major? Not that it would be a problem to include them, but to me a first major version seems like a good moment to drop such APIs, so I thought it was worth the question...


The plan is to indeed remove those deprecations before tagging v1.0, thanks for bringing it up! They haven't been removed yet in case we want to make a final 0.x release with these deprecations still in place.

1 Like

Would it upgrade the version of swift-numerics?

I got error if i write this

dependencies: [
    .package(url: "", from: "1.0.0"),
    .package(url: "", from: "0.2.1"),

You really shouldn’t be using package(name:url:from:) for anything with a major version of 0. You should only be allowing versions that don’t have breaking changes.

By default, 0.y.z versions are all breaking. In the case of Swift Algorithms specifically, pre-1.0.0 patch updates are safe. That’s why you are supposed to use upToNextMinor(from:).

1 Like
Terms of Service

Privacy Policy

Cookie Policy