Skip to content

0.15.2

Latest

Choose a tag to compare

@github-actions github-actions released this 15 Aug 06:32

0.15.2

A dependency-requirement release on top of 0.15.1, closing the same deadlock that release opened up β€” in the one requirement it left behind. No API changes and no rendering or parsing behavior changes.

  1. MachOKit is required as 0.52.101 ..< 0.53.0 instead of exact: "0.52.100" β€” an exact requirement in a library deadlocks any consumer that also depends on MachOKit directly. 0.15.1 fixed this for MachOObjCSection and left MachOKit exact; RuntimeViewer hit it the moment it moved to 0.52.101.
  2. The lower bound moves to 0.52.101, picking up the ObjC header info lookup fix for dyld subcaches.
  3. MachOKitExtensions moves to from: "0.1.1" β€” bind resolution in legacy binaries that carry no chained fixups, and dyld cache image matches that are ranked rather than first-hit.
  4. swift-semantic-string moves to from: "0.3.0", which is what 0.15.1's changelog already claimed while Package.swift still said 0.1.5. The resolved version was 0.3.0 either way, because MachOObjCSection requires it; only the spelling here was stale.
  5. Three retroactive conformances are spelled @retroactive β€” FileHandle and MemoryMappedFile conforming to MachONamespacing, and ObjCClass64 / ObjCClass64.Layout to LocatableLayoutWrapper / LayoutProtocol. Both the types and the protocols live in other modules, so the attribute is what the compiler asks for.
  6. Package.swift no longer reads a .package.env file. Local-dependency switching is environment variables only.

Rendered output is byte-for-byte unchanged.

Highlights

The requirement 0.15.1 did not convert

0.15.1 made the case at length: two exact: requirements on one package have no intersection unless they name the same version, so a library that pins exactly deadlocks every consumer that also depends on that package directly. It converted MachOObjCSection to a range and left MachOKit as exact: "0.52.100".

RuntimeViewer depends on this package and on MachOKit directly. When it moved to 0.52.101 for the subcache fix, resolution stopped having a solution:

error: Failed to resolve dependencies Dependencies could not be resolved because
'runtimeviewercore' depends on 'machoswiftsection' 0.15.1.
'machoswiftsection' 0.15.1 cannot be used because 'machoswiftsection' 0.15.1
depends on 'machokit' 0.52.100 and 'runtimeviewercore' depends on 'machokit' 0.52.101.

Same failure, same shape, one release later. Bumping the pinned version would only move the deadlock to the next MachOKit patch either side wants first, so the requirement itself becomes a range.

The upper bound stops at the next minor rather than opening to 1.0.0, for the reason 0.15.1 gave for MachOObjCSection: this line has removed public API within a minor before, and a wider bound would let a future release float this package onto an incompatible MachOKit.

What 0.52.101 carries

One three-line fix, upstream p-x9/MachOKit#310: ObjC header info lookup resolved against the wrong subcache when reading a split dyld shared cache. Nothing in this package changes shape because of it.

Compatibility

  • No API additions, removals or renames. No snapshot formatVersion change.
  • Consumers that pinned MachOKit to 0.52.100 alongside this package can now move anywhere in 0.52.101 ..< 0.53.0; that is the point of the release.
  • Pinned dependencies for this release β€” the first four lines differ from 0.15.1:
    • MachOKit β†’ 0.52.101 ..< 0.53.0.
    • MachOKitExtensions β†’ from: "0.1.1".
    • swift-semantic-string β†’ from: "0.3.0".
    • MachOObjCSection β†’ 0.8.104 ..< 0.9.0, unchanged and for the reasons given in 0.15.1.
    • swift-demangling β†’ 0.4.5 ..< 0.5.0, unchanged and for the reasons given in 0.14.1.

Requirements

  • Swift 6.2+
  • Xcode 26.0+ (CI validates the test matrix on Xcode 26.6 / macOS 26)