Stronger Inference? (4)

Bug fixes

• Retain inferred property when updating any other property of a core context using a helper function (#352)

Full Changelog: 4.0.0-alpha.1...4.0.0-alpha.2

Stronger Inference?

Bug Fixes

• Retain inferred property value when updating any other property of a core context using a helper function (#352)

Full Changelog: 3.1.1...3.1.2

Early Equality

Non-breaking Changes

• Improvements to AnyCodable equality and ability to encode any Encodable (#351)

Breaking Changes

• Drop support for Swift versions prior to 5.8 (#339)
• Fix typos for serverVarialbeEnumIsValid and serverVarialbeDefaultExistsInEnum (#348)

New Contributors

• @PARAIPAN9 made their first contribution in #348

Full Changelog: 3.1.1...4.0.0-alpha.1

Allowed but not seen

What's Changed

• Simply ensure that jsonSchemaDialect at document root and the $schema keyword within JSON Schemas do not fail to parse (#349)

Full support for these keywords will come with #202.

Full Changelog: 3.1.0...3.1.1

Explicitly Inferred

What's Changed

• Differentiate propertyless requirements (#343) / (#347)
• Fix bug with conversion dropping explode property of parameters (#346)

Identifying required entries that do not refer to properties in the immediate JSON Schema

Take the following two schema snippets:

Foo:
  type: object
  properties:
    a:
      type: string
  required:
    - b

and

Foo:
  type: object
  properties:
    a:
      type: string
    b: {}
  required:
    - b

Prior to this version, both of those snippets would have been represented identically within OpenAPIKit. After this version, the first schema’s “b” property will answer true to the new JSONSchema inferred property and the second schema’s “b” property will answer false. In fact, the only current situation where a JSON Schema is considered "inferred" is when a .fragment schema is produced by an entry in an object's required array that has no matching properties entry on the same object; we say that the existence of such a property is inferred from the fact that such a property being required by name.

Full Changelog: 3.0.1...3.1.0

Maximize Goodness

Bug Fixes

• Fix integer max/min parsing and improve inconsistency errors (#342)

Full Changelog: 3.0.0...3.0.1

A Whole New World

This release of OpenAPIKit brings support for OpenAPI 3.1 in addition to numerous other improvements and a fair number of breaking changes (hopefully all worth their weight!).

The biggest thing to know up front is that you will need to choose between one of two modules:
OpenAPIKit30 is a new module that continues to support the OAS 3.0 (OpenAPI 3.0 standard).
OpenAPIKit is the module that supports the OAS 3.1 (OpenAPI 3.1 standard).

I suggest migrating your code to the OpenAPIKit module if possible. You will need to do a bit more work (in some cases, not all) but this will set you up for the broadest support of OpenAPI Documents.

OpenAPIKit 3.0.0 ships with another module named OpenAPIKitCompat that allows you to turn an OpenAPIKit30.OpenAPI.Document into an OpenAPIKit.OpenAPI.Document (i.e. convert from OAS 3.0 to OAS 3.1). There is not yet support for converting from OAS 3.1 to OAS 3.0, though that is a desirable (if not planned) addition. There is documentation on how to use this conversion to write your code against the OpenAPIKit module but support loading in both OAS 3.0 and OAS 3.1 documents here.

There are two ways to explore the changes between OpenAPIKit v2.x and OpenAPIKit v3.0.0:

1. Read the release notes for each v3.0.0 pre-release (best way to see new features added, most granular information on changes including breaking changes).
2. Read the migration guide (fastest way to get yourself going against the new version).

Formats on Formats (release candidate)

What's Changed

• Adds missing contentMediaType and contentEncoding properties to JSONSchema.string() convenience constructor functions (#334)
• Adds a few more builtin content types I was surprised to have not included already (#335)
• JSON Schema String Format Updates (#337)

Breaking Changes

There are no breaking changes to the OpenAPIKit30 module. The following all apply to the OpenAPIKit module.

• There is no longer .extended formats for .string JSON Schemas. Instead, all existing .extended formats are now just regular .string formats (e.g. you can just replace .extended(.uuid) with .uuid).
• There are no longer .byte or .binary formats for .string JSON Schemas. Instead, use the contentEncodings of .base64 and .binary, respectively.
• The .uriReference .extended JSON Schema .string format used to serialize to uriref whereas the new .uriReference JSON Schema .string format serializes to uri-reference, per the JSON Schema standard.
• The new builtin ContentTypes will not compare equally to custom types created previously (e.g. ContentType.gif is not equal to ContentType.other("image/gif"). If you need such things to compare equally, compare their .rawValue properties.

Full Changelog: 3.0.0-rc.3...3.0.0-rc.4

Niche Content (release candidate)

What's Changed

• Made private helpers private again.
• Added Media Type (contentMediaType) and Encoding (contentEncoding) on JSONSchema in the StringContext.

Full Changelog: 3.0.0-rc.2...3.0.0-rc.3

Well Read (release candidate)

Big thanks to @simonbility for jumping in and making another part of OpenAPIKit order-stable when encoding/decoding.

What's Changed

• Use OrderedDictionary for discriminator mapping (#320)
• propagate nullability from subschemas where appropriate (#322)

Breaking Changes

It is very unlikely, but possible, that the change to OrderedDictionary for the mapping property of the Discriminator type could cause compiler errors if your code is using methods specific to the Dictionary type when working with these mappings.

New Contributors

• @simonbility made their first contribution in #320

Full Changelog: 3.0.0-rc.1...3.0.0-rc.2