3.0.0 is the first release in four years and it is a major version with a fair amount of breaking changes, but the only thing describing it is the auto-generated release note pointing at #101 ("Update to support Swift 6 / Remove obsolete code"). To find out what actually changed and what it means for an app, you have to read a 24-file diff.
It would help a lot if the repo had:
1. CHANGELOG.md
A hand-written, human-readable changelog (Keep a Changelog style is fine), with Added / Changed / Removed / Breaking sections per version. The auto-generated "What's Changed" list of PR titles doesn't convey the impact of a major bump.
2. Migration / upgrade guide for 2.3.0 → 3.0.0
Either a section in the README or a Documentation/Migration-3.0.md. From reading the diff, these are the things an app upgrading from 2.3.0 runs into:
- CocoaPods support dropped —
FuntastyKit.podspec (and Gemfile) removed, SPM only. Worth stating explicitly, including what CocoaPods users should do.
- Umbrella/transitive imports gone — with SPM every file that names a
UI* type now needs its own import UIKit.
@MainActor added across the coordinator API (Coordinator, DefaultCoordinator, ShowCoordinator, PushCoordinator, ModalCoordinator, TabBarItemCoordinator, alert helpers). This propagates into every app-side coordinator/view model and is the single biggest source of compile errors.ErrorAction.ErrorHandler is now @MainActor @Sendable () -> Void, and ErrorAction / ErrorAction.Style / AlertCoordinator.Source / AlertCoordinator.Style are Sendable.- Existential
any required — CoordinatorDelegate → any CoordinatorDelegate, Error → any Error, Deselectable → any Deselectable in public signatures.
- Types removed —
Nibable, StoryboardType / StoryboardReference, HairlineLayoutConstraint, KeyboardHeightConstraint, and the whole FuntastyKitIBInspectable target. A one-line "use X instead" (or "no replacement, copy it into your app") for each would save a lot of guesswork.
- Minimum toolchain / deployment target — which Swift and Xcode version 3.0.0 requires, and whether the minimum iOS target moved.
Even a short bullet list per item ("what changed → what to do in your app") would make the upgrade a mechanical task instead of a diff-reading exercise. Happy to open a PR with a first draft of the migration notes based on what we hit while upgrading, if that's useful.
3.0.0 is the first release in four years and it is a major version with a fair amount of breaking changes, but the only thing describing it is the auto-generated release note pointing at #101 ("Update to support Swift 6 / Remove obsolete code"). To find out what actually changed and what it means for an app, you have to read a 24-file diff.
It would help a lot if the repo had:
1.
CHANGELOG.mdA hand-written, human-readable changelog (Keep a Changelog style is fine), with
Added/Changed/Removed/Breakingsections per version. The auto-generated "What's Changed" list of PR titles doesn't convey the impact of a major bump.2. Migration / upgrade guide for 2.3.0 → 3.0.0
Either a section in the README or a
Documentation/Migration-3.0.md. From reading the diff, these are the things an app upgrading from 2.3.0 runs into:FuntastyKit.podspec(andGemfile) removed, SPM only. Worth stating explicitly, including what CocoaPods users should do.UI*type now needs its ownimport UIKit.@MainActoradded across the coordinator API (Coordinator,DefaultCoordinator,ShowCoordinator,PushCoordinator,ModalCoordinator,TabBarItemCoordinator, alert helpers). This propagates into every app-side coordinator/view model and is the single biggest source of compile errors.ErrorAction.ErrorHandleris now@MainActor @Sendable () -> Void, andErrorAction/ErrorAction.Style/AlertCoordinator.Source/AlertCoordinator.StyleareSendable.anyrequired —CoordinatorDelegate→any CoordinatorDelegate,Error→any Error,Deselectable→any Deselectablein public signatures.Nibable,StoryboardType/StoryboardReference,HairlineLayoutConstraint,KeyboardHeightConstraint, and the wholeFuntastyKitIBInspectabletarget. A one-line "use X instead" (or "no replacement, copy it into your app") for each would save a lot of guesswork.Even a short bullet list per item ("what changed → what to do in your app") would make the upgrade a mechanical task instead of a diff-reading exercise. Happy to open a PR with a first draft of the migration notes based on what we hit while upgrading, if that's useful.