Upstream OCCT release tracking process

[gsdali]

Problem

OCCT releases on a roughly six-month cadence (8.0 → 8.1 → 8.2 → ... → 9.0). Without a deliberate tracking process the bridge layer falls out of date, downstream consumers get blocked waiting for upgrades, and feature work piles up at major boundaries. V1 is the right time to formalize the maintenance discipline.

Goal

Define and document a repeatable process for monitoring, evaluating, and adopting upstream OCCT releases. Owner: OCCTSwift maintainer.

Proposed process

1. Monitor

• Subscribe to upstream release announcements:
  • https://www.opencascade.com/products/occt/ (release notes)
  • https://github.com/Open-Cascade-SAS/OCCT/releases (tags)
  • OCCT mailing list / forum if relevant
• Add to maintainer's regular review cadence (weekly or per-tag, whichever is faster).

2. Score impact

For each upstream release, evaluate against a rubric:

• Bridge surface changes — new APIs added, removed, or with signature changes. Estimate bridge-side LOC delta.
• Behavioral changes — numerical, geometric, or performance changes that could affect consumers (e.g. tessellation defaults, boolean robustness, fillet algorithms).
• Build / dependency changes — third-party library bumps (TBB, freetype, freeimage, etc.), CMake changes, platform-support changes.
• Bugs fixed — anything matching open issues in the OCCTSwift ecosystem.
• New modules / features — anything worth surfacing through the bridge.

3. Decide upgrade window

Based on score, classify each release:

• Skip — minor bug-fix-only release with no consumer-visible impact. Note in CHANGELOG; do not upgrade.
• Absorb in next minor — additive changes, new bridge APIs. Goes into a non-breaking OCCTSwift release.
• Absorb in next major — breaking changes that require consumer migration. Plan via the standard semver-major path.
• Defer — consumer-disruptive but not yet justified by demand; revisit after the next upstream release.

4. Plan and execute

For each adopted release:

• Open a tracking issue in OCCTSwift titled Upgrade to OCCT X.Y.Z.
• Sub-tasks: bridge changes, test additions, consumer migration notes, CHANGELOG entry, release tag.
• Notify downstream consumers (PadCAM, Unfolder, etc.) when a major upgrade is imminent so they can plan their floor-pin bumps.

Documentation

This process lives in MAINTAINERS.md (or CONTRIBUTING.md if you'd rather not split). The first OCCT post-8.0 release (likely 8.1) is the first chance to exercise it — document any deviations as the process matures.

Non-goals

• Committing to a specific upgrade SLA ("every release within N weeks"). The rubric drives timing, not a calendar.
• Automating any of this. A documented manual process is enough; automation is a later concern.
• Tracking non-OCCT upstream dependencies (Swift toolchain, Metal, TBB, etc.). Separate concern.

Acceptance

• MAINTAINERS.md (or equivalent) documents the process.
• The next OCCT release after 8.0.0 GA goes through the rubric and produces a tracking issue.
• Downstream consumers (PadCAM, Unfolder, etc.) know where to look for upcoming upgrade plans.