Swiftpack.co - Swift Packages by tayloraswift

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. this release patches a critical vulnerability that occurs when the *DEFLATE* backend attempts to compress very short inputs (less than 3 bytes) causing a **runtime crash**. for applications using the library for PNG compression, the attack is only effective if the server is asked to compress a 1x1 pixel grayscale image, as all other types of PNG images create data streams that are longer than 2 bytes. all *Swift PNG* users are advised to upgrade to 4.4.1 immediately. *Swift PNG* 4.4 adds gzip compression and decompression tools to the `LZ77` module, and updates the documentation with [examples of how to use gzip compression](https://swiftinit.org/docs/swift-png/lz77#Gzip%20compression) in your app. Internally, *Swift PNG* 4.4 also adopts nested protocols ([SE-0404](https://github.com/apple/swift-evolution/blob/main/proposals/0404-nested-protocols.md)), which makes the documentation easier to navigate but should be an API-transparent change, as all of these protocols were already informally namespaced via `typealias`es. *Swift PNG* 4.4 requires Swift 5.10 or newer. ## Why use *Swift PNG*’s gzip implementation? *Swift PNG*’s native Swift gzip implementation is not as fast as some existing C libraries which are found on many systems. However, a lot of optimization work went into the LZ77 module long ago, and the Swift version should not be *significantly* slower than an equivalent C library. Applications that compress large volumes of data and do little else may be better off calling a system C library instead of using `LZ77`. However the complexity of marshaling data through a C library can often be a disincentive to using compression in more peripheral use cases, and having a convenient, portable Swift library available that still performs reasonably well can help make applications more efficient overall. ## Why is the gzip library still part of *Swift PNG*? The compression backend was written long ago exclusively for *Swift PNG*, and the decision to expose it to external clients was only made recently. The PNG library helps us test the correctness of the gzip backend, as the PNG format is little more than a wrapper around an LZ77 data stream. Applications that depend on the `LZ77` target only will not pull in PNG-related code. ## How can I help? Rewriting the project’s [benchmarks](https://github.com/tayloraswift/swift-png/tree/master/Benchmarks) to use the more-modern [`package-benchmark`](https://github.com/ordo-one/package-benchmark) framework would help us gain better visibility into how the library is performing relative to system C libraries. PRs that add benchmark integrations to the project are likely to be merged. This release is almost entirely focused on documentation, as much of the library’s existing docs had rotted due to evolution of tooling. We have rewritten the package’s examples and tutorials and repaired scores of broken doccomments, and the package’s documentation is [now available](https://swiftinit.org/docs/swift-png/png) on swiftinit.org. This release is focused on separating out the LZ77/DEFLATE implementation from the rest of the library, and making it available for use as a general-purpose data compressor. The package now vends a separate library target, `LZ77`, which exposes the DEFLATE implementation. Currently, only the [`deflate`](https://stackoverflow.com/questions/7243705/what-is-the-advantage-of-gzip-vs-deflate-compression) wrapper format is supported, although we plan on supporting the `gzip` wrapper format in a future release. An example of how to use the new API can be found in the [BasicCompression.swift](https://github.com/tayloraswift/swift-png/blob/master/Snippets/BasicCompression.swift) snippet. While preparing this release, it was discovered that SIMD-accelerated encoding backend was broken on Apple Silicon; a problem that was only uncovered upon upgrading the CI runners to macOS 14. This bug has been fixed in 4.1. Minor concurrency patch: Adds `Sendable` conformances to the built-in generic `RGBA<T>` and `VA<T>` types. <p align="center"> <strong><em>Swift PNG</em></strong> <br/> 4.0.0 </p> ## features - ***Powerful interfaces.*** *Swift PNG*’s expressive, strongly-typed APIs make working with PNG images easy for beginners and advanced users alike. If your code compiles, you’re already most of the way there. Power users can take advantage of [custom indexing](../../tree/master/examples/#using-indexed-images), [manual decoding workflows](../../tree/master/examples/#online-decoding), and [user-defined color targets](../../tree/master/examples/#custom-color-targets). - ***Superior compression***. *Swift PNG* supports minimum cost path-based [*DEFLATE*](https://tools.ietf.org/html/rfc1951) optimization, which is why it offers four additional compression levels beyond what [*libpng*](http://www.libpng.org/pub/png/libpng.html) supports. *Swift PNG* outperforms *libpng* at its highest compression setting by [significant margins](../../tree/master/benchmarks#compression-level-13) for almost all types of input images. - ***Competitive performance.*** *Swift PNG* offers [competitive performance](../../tree/master/benchmarks/) compared to *libpng*. On appropriate CPU architectures, the *Swift PNG* encoder makes use of [hardware-accelerated hash tables](https://engineering.fb.com/2019/04/25/developer-tools/f14/) for even greater performance. - ***Pure Swift, all the way down.*** Aside from having no external dependencies, *Swift PNG* is powered by its own, native Swift *DEFLATE* implementation. This means *Swift PNG* works on any platform that Swift itself works on. It also means that *Swift PNG*’s performance [improves as the Swift compiler matures](../../tree/master/benchmarks#performance-by-toolchain). - ***Batteries included.*** *Swift PNG* comes with [built-in color targets](https://kelvin13.github.io/png/PNG/Color/) with support for [premultiplied alpha](https://kelvin13.github.io/png/PNG/RGBA/premultiplied/). [Convolution](https://kelvin13.github.io/png/PNG/convolve(_:dereference:kernel:)/) and [deconvolution](https://kelvin13.github.io/png/PNG/deconvolve(_:reference:kernel:)/) helper functions make [implementing custom color targets](../../tree/master/examples/#custom-color-targets) a breeze. On MacOS and Linux, *Swift PNG* has built-in file system support, allowing you to [compress](https://kelvin13.github.io/png/PNG/Data/Rectangular/compress(path:level:hint:)/) or [decompress](https://kelvin13.github.io/png/PNG/Data/Rectangular/decompress(path:)/) an image, given a filepath, in a single function call. Other platforms can take advantage of *Swift PNG*’s [protocol-oriented IO](https://kelvin13.github.io/png/PNG/Bytestream/) to implement their own data loading. - ***First-class iPhone optimization support.*** *Swift PNG* requires no custom setup or third-party plugins to handle [iPhone-optimized](../../tree/master/examples/#using-iphone-optimized-images) PNG images. iPhone-optimized images just work, on all platforms. Reproduce [`pngcrush`](https://developer.apple.com/library/archive/qa/qa1681/_index.html)’s output with [bit width-aware alpha premultiplication](https://kelvin13.github.io/png/PNG/RGBA/premultiplied(as:)/), for seamless integration anywhere in your application stack. - ***Comprehensive metadata support.*** *Swift PNG* can parse and validate all public PNG chunks, which are accessible as [strongly-typed metadata records](https://kelvin13.github.io/png/PNG/Metadata/). - ***Modern error handling.*** *Swift PNG* has a fully stateless and Swift-native [error-handling system](https://kelvin13.github.io/png/PNG/Error/). This release addresses `@_specialize` warnings produced by compiler PR [#30962](https://github.com/apple/swift/pull/30962) which affects users using the nightly 5.2+ builds. This release fixes some compiler warnings due to compiler drift from Swift 4.2 to 5.2+, and with the agreement of all contributors, [re-licenses](https://github.com/kelvin13/png/commit/a8c94cc4ef539f8d7300492c6c3d7c3265f44d61) the library under a weaker copyleft license, the Mozilla Public License 2.0. The library has been completely rewritten since version 2.0.1 and now features a much streamlined and improved API, as well as ancillary PNG chunk support, and a wider variety of color format inputs and outputs. Grayscale–alpha and indexed color now have first-class status in the 3.0 API, and are fully integrated with all PNG color backends in the file format’s specification. The typing system has also been greatly strengthened, resulting in an API which returns far fewer optionals, provides more expressive enumerations, and has a much greater chance of catching errors at compile time. This release adds a new overload to `png_encode(path:raw_data:properties:chunk_size:)` that takes a Swift `UnsafeBufferPointer<UInt8>` instead of an `Array`, to avoid having to recopy a foreign array into Swift managed memory.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This release is exactly the same as 1.0.0, except it has been re-licensed under the more permissive MPL-2.0 license. Initial release; supports baseline, extended, and progressive-mode images, images with restart markers, images with DNL segments, and user-defined extensions to the JPEG standard.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. The first production ready release of the *Noise* library, with support for several types of gradient noise (“Perlin noise”), cell noise (“Worley noise” or “Voronoi noise”), poisson disk sampling, and fractal brownian motion, among other things. Documentation is available on the [project wiki](https://github.com/kelvin13/noise/wiki). 

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This release updates the [`swift-grammar`](https://github.com/tayloraswift/swift-grammar) (0.4) and [`swift-testing`](https://github.com/apple/swift-testing) (0.7) dependencies to their next minors, to unblock anyone currently stuck in [dependency hell](https://en.wikipedia.org/wiki/Dependency_hell) due to one or both of those packages. Swift JSON is a Foundation-free JSON parser and encoder written in pure Swift. It is designed to be performant, expressive, and speedy to compile. Swift JSON builds on linux and macOS. As of version 1.0.0, it requires Swift 5.10 or newer. You can get started with Swift JSON by reading its [documentation](https://swiftinit.org/docs/swift-json/json), or by following the [tutorial]( https://swiftinit.org/docs/swift-json/json/decoding). `swift-json` v0.3.0 is finally here! ## obsoleting json dictionary representations version 0.2 of `swift-json` modeled objects (things written in curly braces `{}`) as dictionaries of `String` keys and `JSON` values: ```swift case array([Self]) case object([String: Self]) ``` this is the most obvious representation for a JSON value, it’s convenient for many use cases, and it dovetails nicely with the [`JSON.array(_:)`](https://swiftinit.org/reference/swift-json/json/json.array%28_:%29) enumeration case. however, this representation also comes with [some functional and performance issues](https://forums.swift.org/t/towards-swift-json-0-3-obsoleting-json-dictionary-abstractions/55973), so we have replaced this representation with a array-based `[(key:String, value:JSON)]` representation. this matches APIs vended by [Dictionary](https://swiftinit.org/reference/swift/dictionary.init%28_:uniquingkeyswith:%29) itself. ```swift case object([(key:String, value:Self)]) ``` to convert an object to a `Dictionary`, use one of the [`as(_:uniquingKeysWith:)`](https://swiftinit.org/reference/swift-json/json/json.as%28_:uniquingkeyswith:%29?overload=s4JSONAAO2as_16uniquingKeysWithSDySSABGSgAEm_A2B_ABtKXEtKF) methods on [`JSON`](https://swiftinit.org/reference/swift-json/json/json). ## ergonomics for high-performance decoding APIs previously, users of `swift-json` had to choose between a slow but ergonomic `Decodable`-based API, and a fast but extremely verbose direct decoding API. `swift-json` v0.3 comes with a much more ergonomic API for high-performance decoding. to decode objects, you can now use the [`LintingDictionary`](https://swiftinit.org/reference/swift-json/json/json/lintingdictionary) abstraction, and to decode arrays, you can now use `swift-json`’s [`Array` extensions](https://swiftinit.org/reference/swift/array). in addition to being faster, using these decoding interfaces also gives better error diagnostics when decoding fails. for an example of how to use `LintingDictionary`, see its [associated snippet](https://github.com/kelvin13/swift-json/blob/master/_Snippets/LintingDictionary.swift). ## `RawRepresentable` convenience APIs `swift-json` v0.3 comes with a handful of new convenience APIs for decoding `RawRepresentable` types directly from JSON messages: [``func `as`<StringCoded>(cases: StringCoded.Type) throws -> StringCoded``](https://swiftinit.org/reference/swift-json/json/json.as%28cases:%29?overload=s4JSONAAO2as5casesxxm_tKSYRzSS8RawValueRtzlF) [``func `as`<CharacterCoded>(cases: CharacterCoded.Type) throws -> CharacterCoded``](https://swiftinit.org/reference/swift-json/json/json.as%28cases:%29?overload=s4JSONAAO2as5casesxxm_tKSYRzSJ8RawValueRtzlF) [``func `as`<ScalarCoded>(cases: ScalarCoded.Type) throws -> ScalarCoded``](https://swiftinit.org/reference/swift-json/json/json.as%28cases:%29?overload=s4JSONAAO2as5casesxxm_tKSYRzs7UnicodeO6ScalarV8RawValueRtzlF) [``func `as`<IntegerCoded>(cases: IntegerCoded.Type) throws -> IntegerCoded``](https://swiftinit.org/reference/swift-json/json/json.as%28cases:%29?overload=s4JSONAAO2as5casesxxm_tKSYRzs17FixedWidthInteger8RawValueRpzSZAGRQlF) [``func `as`<UnsignedIntegerCoded>(cases: UnsignedIntegerCoded.Type) throws -> UnsignedIntegerCoded``](https://swiftinit.org/reference/swift-json/json/json.as%28cases:%29?overload=s4JSONAAO2as5casesxxm_tKSYRzs17FixedWidthInteger8RawValueRpzSUAGRQlF) ## avoid working with `swift-grammar` directly version 0.2 of `swift-json` re-exported [`Grammar`](https://github.com/kelvin13/swift-grammar)’s entire API, and expected users to invoke `swift-grammar` parsing rules directly. this was done to reduce the amount of “magic” in the parser, and guide users towards the lowest-overhead parsing configurations needed for their use case, which was important back when `swift-json` was a closed-source library primarily used for fintech applications. however it also made for a very complex API that was hard to learn if you were not already familiar with how `swift-grammar` works. version 0.3 of `swift-json` now comes with a simplified [`init(parsing:)`](https://swiftinit.org/reference/swift-json/json/json.init%28parsing:%29) initializer, which takes UTF-8-encoded input, and just “does the right thing” by default. ## `ExpressibleBy_Literal` conformances the `JSON` type now conforms to [`ExpressibleByArrayLiteral`](https://swiftinit.org/reference/swift/expressiblebyarrayliteral),[`ExpressibleByBooleanLiteral`](https://swiftinit.org/reference/swift/expressiblebybooleanliteral), [`ExpressibleByDictionaryLiteral`](https://swiftinit.org/reference/swift/expressiblebydictionaryliteral), [`ExpressibleByExtendedGraphemeClusterLiteral`](https://swiftinit.org/reference/swift/expressiblebyextendedgraphemeclusterliteral), [`ExpressibleByStringLiteral`](https://swiftinit.org/reference/swift/expressiblebystringliteral), and [`ExpressibleByUnicodeScalarLiteral`](https://swiftinit.org/reference/swift/expressiblebyunicodescalarliteral). ## platform and toolchain support `swift-json` supports swift 5.3 ... 5.8 nightly, and has official CI coverage for linux, macOS, iOS, watchOS, tvOS, and windows. `swift-json` has a [fully-green build matrix](https://swiftpackageindex.com/kelvin13/swift-json/builds) on the swift package index. ## documentation we have expanded `swift-json`’s documentation, and published it on [swiftinit](https://swiftinit.org/reference/swift-json/json). this release contains backported fixes to get this package compiling again with the swift 5.6 toolchain in the wake of [SE-0335](https://forums.swift.org/t/se-0335-introduce-existential-any/53934) being dropped from swift 5.6. it also specifies the [`swift-grammar`](https://github.com/kelvin13/swift-grammar) dependency version more precisely. * fixes some symlink-related problems with editable SPM packages. * adds a more helpful compiler diagnostic when using the deprecated `JSON.IntegerOverflowError.type` property. <div align="center"> ***`json`*** `0.2.0` </div> hi all, about a month ago, we released the experimental [`swift-json` v0.1.0](https://forums.swift.org/t/swift-json-0-1-0-now-available/55067). `swift-json` up to [v0.1.6](https://github.com/kelvin13/swift-json/releases/tag/v0.1.6) only compiles on the swift 5.6 nightlies, and contains executable test targets that only compile on linux, which meant the package as a whole only compiles on a nightly toolchain on a linux platform. as i’m sure many will agree, this is quite silly, so we’ve made it a goal to support at least **three minor swift releases**, as well as **macOS, iOS, watchOS, and tvOS**. as part of the `0.2.0` release, we’re pleased to announce that `swift-json` now supports all the [swift package index](https://swiftpackageindex.com/kelvin13/swift-json) targets, going all the way back to swift 5.3.  look at all that green! as the project has matured, i’ve also set up a [CI pipeline](https://github.com/kelvin13/swift-json/actions/workflows/build.yml) to test a number of platform × toolchain configurations directly in GitHub Actions. **we are now explicitly testing the following platform × toolchain combinations:** * [ build-macos (macos-11) ](https://github.com/kelvin13/swift-json/runs/5354937589?check_suite_focus=true) * [build-macos (macos-10.15) ](https://github.com/kelvin13/swift-json/runs/5354937612?check_suite_focus=true) * [build-linux (ubuntu-20.04, 5.5.3) ](https://github.com/kelvin13/swift-json/runs/5354937381?check_suite_focus=true) * [build-linux (ubuntu-20.04, 5.4.3) ](https://github.com/kelvin13/swift-json/runs/5354937410?check_suite_focus=true) * [build-linux (ubuntu-20.04, 5.3.3) ](https://github.com/kelvin13/swift-json/runs/5354937446?check_suite_focus=true) * [build-linux (ubuntu-18.04, 5.5.3) ](https://github.com/kelvin13/swift-json/runs/5354937465?check_suite_focus=true) * [build-linux (ubuntu-18.04, 5.4.3) ](https://github.com/kelvin13/swift-json/runs/5354937490?check_suite_focus=true) [build-linux (ubuntu-18.04, 5.3.3)](https://github.com/kelvin13/swift-json/runs/5354937519?check_suite_focus=true) (Windows is on the way too!)

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. 0.3.3 is a bugfix release. * #54 * #55 internally, the [`swift-grammar`](https://github.com/kelvin13/swift-grammar) dependency has been upgraded, and the `URI` type has been split off into its own module. v0.3.2 is a transitional release to prepare Biome for version 0.4. it mostly consists of internal changes enabling the service to scale more gracefully. * the time it takes to lookup versioned data no longer increases linearly with number of snapshots * the in-memory database has been re-architected somewhat to make it easier to un-register package snapshots * doccomment inheritance is now a first-class, versioned attribute in Biome’s in-memory database * doccomment pruning logic has moved into `SymbolGraphs`/`swift-symbolgraphc`, mildly improving Biome’s startup time. * `SymbolGraphs`/`swift-symbolgraphc` can now handle SPM snippets * package landing pages now display package dependencies and exact pins ([live example](https://swiftinit.org/reference/mongokitten)) * Biome has been relicensed from GPL 3 → MPL 2 Entrapta 0.1.0.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. updates SPF for the [`swift-DEVELOPMENT-SNAPSHOT-2022-12-17-a`](https://github.com/kelvin13/swift-package-factory/commit/babb16e83198e53da6541cb19978d3e3356a3ab8) toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-11-11-a` toolchain. updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-11-01-a` toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-10-11-a` toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-10-03-a` toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-09-29-a` toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-09-27-a` toolchain updates SPF for the `swift-DEVELOPMENT-SNAPSHOT-2022-09-24-a` toolchain. updates SPF for the `DEVELOPMENT-SNAPSHOT-2022-09-12-a` toolchain. updates SPF for the `DEVELOPMENT-SNAPSHOT-2022-09-10-a` toolchain

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. The [`swift-dom`](https://github.com/tayloraswift/swift-dom) library is a cross-platform, efficient, expressive DSL for generating HTML (and related formats) with few intermediate allocations. ```swift $0[.li] { $0[.p] { $0.class = "album" } = "Tortured Poets Department" } ``` ## Why another HTML DSL? Many HTML libraries are built around the idea of an [Abstract Syntax Tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) (AST). You build up a tree of nodes that represents the structure of the document, and then a rendering engine performs a tree traversal to generate the HTML. This is an intuitive mental model for many developers, and dovetails well with Swift result builders and Swift’s general ethos of immutable value semantics. On the other hand, AST-based rendering can use a lot of memory, as it involves a large number of intermediate allocations. AST-based data structures also struggle with static typing, as they must balance the internal need to model the polymorphic nature of HTML nodes with the external need to present a type-safe API. Many AST-based HTML libraries mitigate this problem by providing voluminous convenience APIs and multiple levels of abstraction, but these APIs do not always compose well, and can be difficult to learn. The large number of “concise” spellings also tends to trip up AI code generation tools who struggle to distinguish between real and imaginary APIs. ## Philosophy Swift DOM is designed to be **composable and easy to learn**, with a small number of patterns that developers must internalize. Instead of outlawing as many invalid states as possible at compile-time, Swift DOM relies on a small number of high-impact static typing rules to eliminate common mistakes without confusing developers with too many highly-specialized guardrails. The tradeoff is that some understanding of the HTML format is required to use Swift DOM correctly, as the library makes no effort to abstract away the underlying markup language. ## Tutorials We suggest reading the library tutorials to get started with the DSL. [Getting started with HTML in Swift](https://swiftinit.org/docs/swift-dom/html/getting-started) [Using protocols with HTML in Swift](https://swiftinit.org/docs/swift-dom/html/using-protocols) [Using inline SVG with HTML in Swift](https://swiftinit.org/docs/swift-dom/html/using-inline-svg) ## Who is using it? The library has been in use on [Swiftinit](https://swiftinit.org) for over **one year**, and produces all of the HTML and SVG graphics on the site. Swift DOM 1.0 is our first attempt to open-source the DSL. ## What platforms does it support? Swift DOM is written in **pure Swift**, and works on Linux, macOS, iOS, watchOS, and tvOS. The [`HTML` product](https://swiftinit.org/docs/swift-dom/html) does not link Foundation. You can view the full compatibility matrix on [The Swift Package Index](https://swiftpackageindex.com/tayloraswift/swift-dom). Swift DOM requires Swift 5.10. v0.5.2 is a bugfix release resolving a segfault that occurs when serializing very long HTML attributes. v0.5.1 adds convenience API to [`HTML.Element`](https://swiftinit.org/reference/swift-dom/html/html/element), [`RSS.Element`](https://swiftinit.org/reference/swift-dom/rss/rss/element), and [`SVG.Element`](https://swiftinit.org/reference/swift-dom/svg/svg/element) to initialize them from raw UTF-8 data. v0.5.0 adds definitions for all the HTML, RSS, and SVG attributes, as indexed by MDN: * https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes * https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute it also adds generated API for all attributes and element types for use with IDE code completion. finally, v0.5.0 introduces a more efficient inline storage optimization for UTF-8 text that is less than 23 characters long, which should greatly reduce the number of heap allocations performed while using this library.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. version 0.4.0 introduces the `blame` tool, which can be used to attribute dependencies to their direct consumers. ## running `blame` To use `blame`, pass it a list of target names: ```bash $ swift package blame Atomics NIOCore ``` ```text direct consumers of Atomics: 0. NIOEmbedded (in 'swift-nio') 1. NIOPosix (in 'swift-nio') direct consumers of NIOCore: 0. NIO (in 'swift-nio') 1. NIOEmbedded (in 'swift-nio') 2. NIOPosix (in 'swift-nio') 3. NIOSSL (in 'swift-nio-ssl') 4. NIOTLS (in 'swift-nio') ``` version 0.3.0 brings support for [SE-0356: Swift Snippets](https://github.com/apple/swift-evolution/blob/main/proposals/0356-swift-snippets.md). version 0.3.0 contains changes to the `Package.catalog` format: * adds a `"snippets"` field to the emitted `Package.catalog` files, * bumps the `"catalog_tools_version"` marker to `3`. this release fixes a bug in 0.2.0 where the plugin was failing to recursively explore all of a targets dependencies, if the target was part of the same package as the target being scanned.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This release renames the `Testing` module to `Testing_` to deconflict with the module of the same name in the [swift-testing](https://github.com/apple/swift-testing) library. Although SwiftPM module aliases enable building despite the name conflict, it causes major tooling problems in VSCode. In 0.3.4, the `AsyncTests` and `SyncTests` protocols became deprecated, and have been replaced with `TestMain` and `TestBattery`. The minimum toolchain requirement increased from 5.7 to 5.8. The most important change in 0.3.3 is that swift-grammar is now the host of the `Testing` module, which it shares with `swift-mongodb` and `swift-unidoc`. the `swift-grammar` 0.2 release is focused around broadening the library’s range of use cases over the v0.1.x releases, during which `swift-grammar` existed more or less to support [`swift-json`](https://github.com/kelvin13/swift-json) and a handful of other parsers. notably, `swift-grammar` v0.1.5 did not ship with a complete alphabet. it included only the definitions needed by its specific consumer packages. it was also not previously possible to disambiguate a name collision with one of the toplevel symbols in this module, since it defines a namespace enum of the same name as the module. v0.2.0 of `swift-grammar` now ships with a [complete ASCII table](https://swiftinit.org/reference/swift-grammar/grammar/unicodeencoding), and has deprecated the `Grammar` namespace enum, which we will be able to remove in v0.3.0. API has been carefully resettled into other namespaces, or (in a few cases) promoted to the toplevel, and migration typealiases have been added to help users transition. v0.2.0 also adopts primary associated types (PATs). this feature is gated to swift >= 5.7; users building on older toolchains will receive a polyfill generated by [`swift-package-factory`](https://github.com/kelvin13/swift-package-factory). finally, v0.2.0 adds CI coverage for iOS, watchOS, and tvOS, and also adds CI coverage for nightly toolchains on macOS and linux. we have also verified that [every swiftpackageindex.com build](https://swiftpackageindex.com/kelvin13/swift-grammar/builds) is succeeding! [browse the API docs](https://swiftinit.org/reference/swift-grammar/grammar)

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. * relaxes the input requirement of `Base16` and `Base64` decoders to skip over non-digit characters. (previously, the library was interpreting them as zeroes). adds support for password-based key derivation (PBKDF2). this is a minor version bump because HMAC APIs have changed in a breaking manner. instead of ```swift let hmac:SHA256 = .hmac(message, key: key) ``` now do: ```swift let hmac:SHA256 = .init(authenticating: message, key: key) ``` v0.4.0 also expands test coverage. * vastly simplifies the litany of `Base16` encoding and decoding APIs. * adds support for `Base64` encoding and decoding. * improves test coverage * improves docstring coverage v0.2.3 of `swift-hash` adds [`RandomAccessCollection`](https://swiftinit.org/reference/swift/randomaccesscollection) conformance to [`SHA256`](https://swiftinit.org/reference/swift-hash/sha2/sha256), and adds support for [`CRC32`](https://swiftinit.org/reference/swift-hash/crc/crc32) hashes.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. - greatly simplifies the BSON encoding protocol hierarchy: - `BSONWeakEncodable` no longer exists, and has been folded into `BSONEncodable` - `MongoExpressionEncodable` no longer exists; instead the expression operator API has been renamed from `init` to `expr` to aid typechecking without the need for a parallel encoding protocol - `Mongo.ExpressionList` and its encoder no longer exist - adds a protocol `MongoExpressionVariable` which provides useful API for types modeling expression variables (e.g. `$$self`) - adds a few missing expression operators - renamed `MongoFieldPathEncodable` to `MongoKeyPathEncodable` this release includes improved support for inspecting raw BSON, and adds support for the generic `Mongo.Explain` command. this release adds support for the following MongoDB commands: - `Mongo.CreateIndexes` - `Mongo.Delete` - `Mongo.Drop` - `Mongo.DropIndexes` - `Mongo.FindAndModify` - `Mongo.RenameCollection` this release adds support for the MongoDB [update command](https://www.mongodb.com/docs/manual/reference/command/update/). this release suppresses some compiler warnings on the 5.8 toolchain. this release bumps the swift-nio dependency to 2.53.0. - changes the semantics of `Int` to use a variable-length (32-bit or 64-bit) BSON encoding. this change also affects type inference of `BSON.AnyValue<Storage>` integer literals. - updates documentation to emphasize that `Int32` and `Int64` are the dedicated standard library types with fixed-length BSON encodings. - generalizes the `BSON.ListShape` assertion API to `BSON.Shape`, and enables it for `BSON.BinaryView<Storage>`. - adds API for asserting BSON binary array subtypes.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Version 0.4.0 renames the package from `swift-resource` to `swift-web-semantics`, and includes the following changes: * introduces the `WebService` protocol, which can be used to factor out dependencies on SwiftNIO, SwiftNIOSSL, etc. * removes the `Resource` type, and folds it into an improved `WebResponse` type. * renames `Response` to `WebResponse`. * moves `WebResponse` into its own module (`WebSemantics` now re-exports it.)