Update Release Workflows, Merge CI and CD Workflows

[XXXXRT666]

The previous release (e.g., opencc-1.2.0-cp311-cp311-manylinux2014_x86_64.whl) is tagged as manylinux2014, however, the actual glibc requirement is 2.33.

This workflow have been tested on TestPyPI

Related Issues: #913 #892 #832 #424 #420 #419 GPT-SoVITS#1513

GLIBC Requirements

wget https://files.pythonhosted.org/packages/cp311/o/opencc/opencc-1.2.0-cp311-cp311-manylinux2014_x86_64.whl -nv
unzip -q  opencc-1.2.0-cp311-cp311-manylinux2014_x86_64.whl
llvm-readelf --version-info ./opencc/clib/opencc_clib.cpython-311-x86_64-linux-gnu.so | grep -Eo 'GLIBC_[0-9]+\.[0-9]+' | sort -Vu

GLIBC_2.2
GLIBC_2.3
GLIBC_2.4
GLIBC_2.14
GLIBC_2.32
GLIBC_2.33

wget https://test-files.pythonhosted.org/packages/bb/05/579237a07fb0f455f459d9b6e4b82414b50982c920429e153e4a6e934cd9/opencc_xxxxrt-1.2.0-cp311-cp311-manylinux2014_x86_64.manylinux_2_17_x86_64.whl -nv
unzip  -q opencc_xxxxrt-1.2.0-cp311-cp311-manylinux2014_x86_64.manylinux_2_17_x86_64.whl 
llvm-readelf --version-info ./opencc/clib/opencc_clib.cpython-311-x86_64-linux-gnu.so | grep -Eo 'GLIBC_[0-9]+\.[0-9]+' | sort -Vu

GLIBC_2.2
GLIBC_2.4
GLIBC_2.14
GLIBC_2.16

[XXXXRT666]

Since this workflow uses OIDC, the Trusted Publisher configuration must be updated on PyPI

[frankslin]

Thank you for the contributions. I noticed two issues:

1. The new wheel matrix seems to drop macOS x86_64 entirely. Today we still build/package on both macos-latest and macos-14, so this looks like a user-visible regression for Intel Mac installs. Could we keep an x86_64 macOS wheel target (or switch to a universal2 strategy) before merging?
2. This refactor narrows coverage from the current 3.8–3.14 matrix to wheel builds on 3.10–3.13 plus a single 3.12 lint check. Is that intentional? If not, we should preserve at least some install/test coverage for older versions 3.8/3.9 and newer 3.14, or explicitly document a new minimum supported Python version before merging.

[XXXXRT666]

1. The new wheel matrix seems to drop macOS x86_64 entirely. Today we still build/package on both macos-latest and macos-14, so this looks like a user-visible regression for Intel Mac installs. Could we keep an x86_64 macOS wheel target (or switch to a universal2 strategy) before merging?

Not entirely. It still provides a source distribution, so users can install via pip and build from source. It only drops prebuilt wheel releases.

2. This refactor narrows coverage from the current 3.8–3.14 matrix to wheel builds on 3.10–3.13 plus a single 3.12 lint check. Is that intentional? If not, we should preserve at least some install/test coverage for older versions 3.8/3.9 and newer 3.14, or explicitly document a new minimum supported Python version before merging.

Since Python 3.8/3.9 has reached EOL, I removed CI/CD support for it. Tests are preserved for all wheels from Python 3.10 through 3.14

[XXXXRT666]

Today we still build/package on both macos-latest and macos-14, so this looks like a user-visible regression for Intel Mac installs

I didn't find an x86_64 wheel for macOS here PyPI

[XXXXRT666]

... and newer 3.14

Sorry, I accidentally dropped the commit that added Python 3.14 support during a rebase. It has now been restored, and both Python 3.14 and 3.14t are supported

[frankslin]

I see. The release-pypi-macos.sh script now supports both arm64 and x86_64 depending on the runner architecture, but in CI we currently only execute it on macos-14, which is arm64. As a result, only arm64 wheels are being produced.

To generate x86_64 wheels as well, we would need to run the job on an Intel runner (e.g., macos-13). This is outside the scope of this PR.

[BYVoid]

@XXXXRT666 I am a bit concerned about this change, because by removing the manual release scripts, we will have to depend on Github's workflow to release a new version to PyPi.

[XXXXRT666]

@XXXXRT666 I am a bit concerned about this change, because by removing the manual release scripts, we will have to depend on Github's workflow to release a new version to PyPi.

Building against lower glibc requires Docker, which is quite heavy for a simple script

With GitHub Actions, we still keep manual triggering, and the workflow will stop before publishing if build or tests fail, so nothing will be pushed to PyPI in that case.

Also, the workflow runs on all PRs as checks. The artifacts contain the built wheels — if needed, we can download them and upload to PyPI manually.

[XXXXRT666]

It also looks like the current wheels are already being built via GitHub Actions? The macos-14 runner is arm64 so it conflicts with macos-latest wheels, so release-pypi (macos-14) job fails