Publish a current CocoaPods release

[janesy]

[roMummy]

Maybe the author forgot to update.
You can use:

pod 'InterposeKit', :git => 'git@github.com:steipete/InterposeKit.git'

[tgrushka]

Bad news. Trying to use this in a Flutter plugin. Can't add git or version in myproject.podspec because of some arbitrary limitation by the Pod authors, because well, no one would ever want to specify a version in a podspec, even when there is no "main" Podfile. All docs regarding prepareHook are therefore moot! Please update!

[steipete]

Maintainer review, June 11, 2026:

• CocoaPods currently publishes only InterposeKit 0.0.1.
• Git tag 0.0.2 exists, but its checked-in podspec still declares 0.0.1, omits Objective-C implementation files from source_files, and has no GitHub Release. The corrected podspec landed later on master.
• A code PR cannot repair the CocoaPods registry entry. Retroactively publishing the stale 2020 tag would also omit years of fixes now on master.

Recommended release path: decide #36, then cut one current version from master and publish that same version to CocoaPods. This needs explicit release authorization and CocoaPods credentials, so the issue remains open as a maintainer product/release decision.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 11, 2026, 8:46 AM ET / 12:46 UTC.

Summary
Keep open. CocoaPods still publishes only InterposeKit 0.0.1, and the remaining work is a maintainer-owned release/publication decision rather than a source-only fix.

Reproducibility: not applicable. as a code bug. The release state is directly verifiable: CocoaPods trunk reports only 0.0.1, while current master has newer package metadata that has not been published.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A maintainer needs to authorize the release/version, decide the open release-content PR, and publish with CocoaPods credentials; this is not safe for an automated fix PR.

Review details

Best possible solution:

Decide #36, cut one approved current version from master, create matching release/tag metadata, and publish that same version to CocoaPods.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a code bug. The release state is directly verifiable: CocoaPods trunk reports only 0.0.1, while current master has newer package metadata that has not been published.

Is this the best way to solve the issue?

Yes, the maintainer-guided release path is the narrowest maintainable solution. A source-only change would not update CocoaPods, and publishing the old tag would ship stale metadata.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• A source PR cannot publish or repair the CocoaPods registry entry; that requires maintainer-owned CocoaPods credentials and release authorization.
• Publishing the old 0.0.2 tag would use stale package metadata and omit current master fixes.
• The exact release contents depend on whether Support weak references for object interposers #36 should land before the next CocoaPods publication.

Codex review notes: model internal, reasoning high; reviewed against 2492331dd962.

Label changes

Label changes:

• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P2: CocoaPods users cannot consume current InterposeKit fixes through the registry, but this is bounded release work rather than an emergency runtime failure.
• impact:other: The issue affects package distribution and dependency availability, which is maintainer-visible but outside the more specific impact taxonomy.

Evidence reviewed

What I checked:

• CocoaPods registry still old: The CocoaPods trunk API lists only InterposeKit 0.0.1 as published, so the requested public package release has not happened.
• Current podspec is corrected on master: Current master declares s.version 0.0.2 and includes Objective-C implementation files in source_files, so source metadata improved but still needs publication. (InterposeKit.podspec:3, 2492331dd962)
• Existing 0.0.2 tag is stale: The 0.0.2 tag points at 17853ad and its podspec still declares 0.0.1 and omits .m files from source_files, so retroactively publishing that tag would not be a current release. (InterposeKit.podspec:3, 17853ad69961)
• No GitHub release exists: The GitHub releases API returned an empty release list for steipete/InterposeKit, matching the maintainer note that there is no current GitHub Release to pair with CocoaPods.
• Maintainer release guidance: The owner comment from June 11, 2026 says to decide Support weak references for object interposers #36, then cut one current version from master and publish that same version to CocoaPods with release authorization and credentials.
• Package history provenance: git blame ties the 0.0.2 version line to 2d48227 and the current .m source_files correction to ebe65e8, showing the current source state is newer than the published registry state. (InterposeKit.podspec:9, ebe65e8385b4)

Likely related people:

• steipete: Peter authored the initial podspec lineage, corrected the current source_files entry on master, owns the current release guidance in the issue discussion, and authored recent release-relevant fixes now awaiting publication. (role: repository owner and release decision owner; confidence: high; commits: 100c948bfea2, c4522b0d1c82, ebe65e8385b4; files: InterposeKit.podspec, README.md, CHANGELOG.md)
• rmigneco: Ray's merged podspec update changed the checked-in version to 0.0.2 for CocoaPods consumers, which is the central package metadata path involved here. (role: prior CocoaPods contributor; confidence: medium; commits: 2d48227c359b; files: InterposeKit.podspec)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

InterposeKit is old and no longer supported, and this repository is being archived. We will not publish another CocoaPods or GitHub release, so I am closing this request.