5.0: Swift Compatibility

Yes I did get tired of my lazy naming scheme.

5.0 adds explicit support for Swift 5 across all dependency management solutions. There are no other user-facing changes.

4.2: four point two

This release (which never hit master, weirdly enough) adds support for the Swift 4.2 and 5.0 toolchains.

4.1.2: The Iteration Generation

• [FIXED]: Now using Iterator instead of Generator in our definition of decode for Collections. This was renamed in Swift 3.0, and honestly I'm not positive how this was compiling the way it was.

4.1.1: An Actual Useable Library

• [FIXED]: Fixed compilation when building via Swift Package Manager

4.1: Optional Packages

• [NEW]: Swift Package Manager Support (Gordon Fontenot)
• [NEW]: Re-introduced Decoded.optional with better, simplified behavior (Tony DiPasquale)
• [FIXED]: Use NSNumber transformation properties instead of casting to decode number values. This now prevents a crash that could occur with Swift 3.0.1 (Gordon Fontenot)

4.0.0: Swift 3 and Multi-Error Debugging

Official Swift 3.0 release!

• [NEW]: Now you can see all the decoding failures at once! Thanks @klaaspieter
• [Bug Fix]: Optional decoding now behaves as expected. Thanks @pteasima for finding this.

Thanks @gfontenot, @alexwlchan, @mbrandonw, @gcox, and @klaaspieter for all the changes that went into this release!

3.1: unsigned unmastered.

3.1 adds support for decoding UInt and UInt64 types. UInt can only be decoded JSON.Number instances, and UInt64 can be decoded from JSON.Number as well as JSON.String. This follows the patterns already set up by Int and Int64.

Thanks to @gcox for this addition!

3.0.3: Now With Different XML

3.0.3 adds improved support for Xcode 8 by slightly modifying the xml in ways that it suggests (Thanks @ikesyo!)

3.0.2: Xcode optimizations

This release is a back-port of our support for enabling whole module optimization (currently supported on master, but unreleased), as well as support for Xcode 8 using Swift 2.3.

3.0.1: NumberWang

Argo 3.0 changed the way Booleans were decoded and in doing so, accidentally broke JSON parsing for APIs that didn't quite follow the JSON spec. Specifically, @jshier noted that it's moderately common for APIs to return 1 or 0 instead of true or false..

To address this, we've re-added the capability of Argo to recognize Bool values represented in the JSON as numbers.