Proposal: Release a capstone6 package for the next major version #2850
Description
Hi!
I’d like to propose that the next major version of Capstone, which introduces extensive breaking changes, be released under a new PyPI package name, capstone6, rather than overwriting the existing capstone package.
Here are the main reasons for this approach:
1. Breaking changes are too extensive
The upcoming version contains major API and semantic changes that make backward compatibility with capstone 5.x infeasible. Attempting to maintain a compatibility layer would either:
- Introduce significant maintenance overhead, or
- Result in a compromised API that is confusing for users.
Releasing a separate package signals clearly that this is a next-generation API.
2. Python packaging model limitations
Python packages are identified by their top-level import name. Two versions of capstone cannot coexist in the same environment.
By creating a new package (capstone6), users and downstream projects can install both versions side-by-side
3. Compatibility with Linux distributions
Debian, Arch, and other distros ignore requirements.txt constraints and package libraries system-wide.
If capstone v6 overwrites capstone v5, this can lead to:
- Build failures for downstream packages depending on
capstone v5 - Frustration for system package maintainers
- Delayed adoption of the new major version
A new package avoids these issues entirely.
This approach minimizes user friction, supports distro maintainers, and avoids technical debt from compatibility shims.
Thank you for considering this proposal!