Remove the release workflow that could never publish

[oscarvalenzuelab]

Problem

release.yml triggered on a v* tag push, built the package, then uploaded it with pypa/gh-action-pypi-publish and no environment:. The PyPI trusted publisher for this project is configured for python-publish.yml with the pypi environment, so the claims from release.yml could never match:

invalid-publisher: valid token, but no corresponding publisher
workflow_ref: SemClone/src2purl/.github/workflows/release.yml@refs/tags/v1.3.5
environment: MISSING

The v1.3.5 run was the first time this workflow ran at all. It did not exist as of the v1.3.4 tag, having arrived later with the workflow standardization changes.

The failure had a second effect that made it look worse than a failed upload: Create GitHub Release was a later step in the same job, so a tag push produced no GitHub release either.

Why remove it instead of fixing the upload

Dropping only the upload step and keeping the release creation would have been worse than the current state. A release created by a workflow using GITHUB_TOKEN does not raise the release: published event, so python-publish.yml would not start. A tag push would then produce a GitHub release with nothing published to PyPI, and the failure would be silent rather than red.

Making the upload work from release.yml instead would need a second trusted publisher entry on PyPI for that workflow, which is duplicate configuration for a path that is already covered.

Releases 1.3.2 through 1.3.5 were all published by a user creating the GitHub release, with python-publish.yml picking up the event. Every release is user-authored, none by github-actions[bot], and all have zero attached assets, confirming release.yml never created one. That path works and is untouched here.

This also matches SemClone/mcp-semclone, which has no release.yml and publishes reliably.

Changes

• Delete .github/workflows/release.yml.
• Document the release steps in CONTRIBUTING.md, which had no release section: version bump, tag, gh release create --generate-notes. Records why step 3 has to be a user action, and that the upload should be verified against the version-specific PyPI endpoint since the aggregate one is cached and lags.

Publishing behaviour is unchanged. python-publish.yml, test.yml, pr-validation.yml and license-check.yml are untouched, and nothing referenced release.yml.

Note

The same release.yml pattern, PyPI upload with no environment, is present in purl2notices, purl2src and upmex, where its runs also fail, and in ossnotices, where it has never run. Those are out of scope here.