Skip to content

v1.5.1 — fix OCCTSwiftIO cap conflicting with OCCTSwiftTools

Latest

Choose a tag to compare

@gsdali gsdali released this 20 Jul 12:40
c8fc205

Raises the OCCTSwiftIO floor from .upToNextMinor(from: "1.0.0") (>=1.0.0, <1.1.0) to from: "1.7.5". The old cap conflicted with OCCTSwiftTools 1.6.1's own OCCTSwiftIO >= 1.7.0 requirement, so any consumer depending on both OCCTSwiftScripts and OCCTSwiftTools directly (e.g. OCCTMCP) could not resolve both at their latest versions — SwiftPM reported an unsatisfiable version conflict, forcing a workaround pin to OCCTSwiftScripts 1.4.1 and its pre-BRepGraph-rename ScriptHarness/DrawingComposer.

The heavy mesh-IO stack (SwiftPMX/SwiftGLTF/ThreeMF/SwiftJWW/SwiftX) pulled in by OCCTSwiftIO remains unavoidable — confirmed OCCTSwiftIO 1.7.5's own OCCTSwiftIO target has an unconditional dependency on its MeshIO target, not something a consumer can decline at the product level. Grepping OCCTSwiftIO's own source shows no file there actually imports MeshIO, so that dependency may be vestigial upstream, but that's a separate, out-of-scope cleanup for the OCCTSwiftIO repo, not fixable here.

Verified with the actual regression test for this bug: a throwaway root package depending on both this fix and OCCTSwiftTools 1.6.1 directly (mirroring OCCTMCP's shape) resolves cleanly, with occtswiftio landing on 1.7.5, satisfying both floors simultaneously. No public API or behaviour change to OCCTSwiftScripts itself.

Closes #80.