Proposal: optional native parser backend with pure-Python fallback #474

Activity

1. tomschr commented on Aug 30, 2026

   

   tomschr

   on Aug 30, 2026

   Member

   More actions

   Thank you, @lowmiaq-gmail, for your proposal! 👍 The performance are compelling, and I appreciate your idea.

   My primary goal is to ensure the project remains simple and has a very low maintenance footprint. It's just a hobby for me and I do this in my free time. This is especially important as I don't know Rust, so if you were to step away, I couldn't maintain the native backend myself.😉 While I appreciate your offer, I'm cautious about adding a native component as it introduces long-term complexity and risk that would fall to me.

   However, I am open to the idea if we can establish a clear framework to address these concerns. To feel comfortable moving forward, how do you think we could best address the following points?

   I'd like to discuss the following principles:

   1. Maintenance & Ownership: How do you see the maintenance of the Rust backend working long-term? To keep the main python-semver repository simple and pure Python, my preference would be to keep the Rust code in a separate repository. This could be hosted under the python-semver organization or at a location of your choice. How would you see the ownership of that package working to ensure it's sustainable if you're no longer involved?

   2. Integration & Safety: What's the best way to integrate the two parsers to guarantee they always produce the exact same results? How can we ensure that a bug fix in one implementation is always mirrored in the other?

   3. Packaging & Distribution: What would the release process for the native wheels look like? How can we ensure it's fully automated and doesn't add a manual burden for project maintainers for each new release?

   Thanks, looking forward to discuss this with you!
2. lowmiaq-gmail commented on Sep 1, 2026

   

   lowmiaq-gmail

   on Sep 1, 2026 via email

   ContributorAuthor

   More actions

   Hi Tom, I appreciate your reply. And first, thank you for maintaining python-semver in your free time. I completely understand why keeping the project simple and low-maintenance matters, especially if Rust isn’t something you want to take on yourself. I’m mainly a Rust enthusiast, and I’ve been working on several optional Rust acceleration projects around Python libraries. So this isn’t really a one-off experiment for me. It’s an area I enjoy, and I’d like to keep contributing this kind of work back to the Python ecosystem. That said, I don’t think python-semver should have to rely on a promise that I’ll maintain a Rust backend forever. I think the safer model is to design it so that even if I stop maintaining it one day, python-semver itself is unaffected. For the three points you raised, this is how I would approach them. *1. Maintenance & ownership* I agree with keeping the Rust code in a separate repository. My preference would be to keep it under my account initially. That keeps the responsibility clear: I maintain the Rust code, CI, wheels, releases, and packaging. The python-semver repository would only contain the small optional integration. If the backend grows and there is a reason to move it under the python-semver organization later, I’d be happy to do that as well. More importantly, the backend should be safe to abandon. The existing pure-Python implementation stays the default and remains fully functional on its own. If the Rust backend ever becomes unavailable or stops being maintained, normal python-semver users should not notice anything. The optional native integration could simply be deprecated or removed. So maintaining Rust should never become a requirement for maintaining python-semver. *2. Keeping the implementations in sync* I would treat the Python implementation as the source of truth for behavior. The Rust parser shouldn’t introduce its own semantics. Its job is only to reproduce python-semver’s behavior faster. I also don’t want this to depend on someone remembering to update both implementations manually. My thought is to make compatibility part of the backend CI: - run the relevant python-semver tests against the Rust backend; - add regression cases when parser bugs are fixed upstream; - continuously compare the Python and Rust parsers on a generated/differential corpus; - cover valid, invalid, boundary, prerelease, and build-metadata cases; - block backend releases if the two implementations disagree. The current prototype already compares 10,000 cases with zero mismatches. I’d turn that into a permanent check rather than treating it as a one-time result. It could also periodically test against python-semver’s main branch, so upstream behavior changes are detected before a backend release. I wouldn’t claim that two independent implementations can never contain a bug. But we can make the Python implementation authoritative and make divergence something CI detects automatically rather than something maintainers have to coordinate by hand. And if there is any uncertainty about the native backend, falling back to the Python parser should always be the safe behavior. *3. Packaging & releases* I agree that python-semver maintainers shouldn’t have to build, test, or upload native wheels. That would all live in the backend repository. The release path I have in mind is roughly: - PyO3/maturin for the extension; - GitHub Actions for the build matrix; - automated Linux, macOS, and Windows wheels; - install/test the built wheels before publishing; - run the upstream and differential compatibility checks; - publish through PyPI Trusted Publishing. So from the python-semver side, there shouldn’t be any extra native release work. The backend can also have its own release cycle. A python-semver release wouldn’t automatically require a Rust release unless something relevant to the parser contract changed. The boundary I have in mind is basically: *python-semver owns the API and semantics; the Rust project owns the optimization and all of the Rust-specific maintenance.* If that model addresses the concerns you had in mind, I’m happy to turn the prototype into the smallest possible PR so you can review the actual maintenance footprint rather than committing to a larger design up front. And if you’d prefer a different ownership arrangement for the backend repository, I’m open to that too. Just let me know. Tom Schraitle ***@***.***>于2026年8月31日 周一00:28写道：

   …

   *tomschr* left a comment (python-semver/python-semver#474) <#474 (comment)> Thank you, @lowmiaq-gmail <https://github.com/lowmiaq-gmail>, for your proposal! 👍 The performance are compelling, and I appreciate your idea. My primary goal is to ensure the project remains simple and has a very low maintenance footprint. It's just a hobby for me and I do this in my free time. This is especially important as I don't know Rust, so if you were to step away, I couldn't maintain the native backend myself.😉 While I appreciate your offer, I'm cautious about adding a native component as it introduces long-term complexity and risk that would fall to me. However, I am open to the idea if we can establish a clear framework to address these concerns. To feel comfortable moving forward, how do you think we could best address the following points? I'd like to discuss the following principles: 1. Maintenance & Ownership: How do you see the maintenance of the Rust backend working long-term? To keep the main python-semver repository simple and pure Python, my preference would be to keep the Rust code in a separate repository. This could be hosted under the python-semver organization or at a location of your choice. How would you see the ownership of that package working to ensure it's sustainable if you're no longer involved? 2. Integration & Safety: What's the best way to integrate the two parsers to guarantee they always produce the exact same results? How can we ensure that a bug fix in one implementation is always mirrored in the other? 3. Packaging & Distribution: What would the release process for the native wheels look like? How can we ensure it's fully automated and doesn't add a manual burden for project maintainers for each new release? Thanks, looking forward to discuss this with you! — Reply to this email directly, view it on GitHub <#474?email_source=notifications&email_token=BSI6YYD5T3YX7XBZ2L2BZ6T5MRI4JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWHE4DQMZZGY32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5469883967>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BSI6YYAIPLYCWRPMKNJ6SML5MRI4JAVCNFSNUABDKJSXA33TNF2G64TZHMZTGNZVG4ZDMO2JONZXKZJ3GUZDONBVGQ3TANJTUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BSI6YYDW6QSDQGLZU3YVUG35MRI4JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWHE4DQMZZGY32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BSI6YYDE3GY4JDUIN5FONXT5MRI4JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWHE4DQMZZGY32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>
3. tomschr commented on Sep 1, 2026

   

   tomschr

   on Sep 1, 2026

   Member

   More actions

   My preference would be to keep it under my account initially.

   I'm fine with that too. 👍

   I wouldn’t claim that two independent implementations can never contain a bug.

   In that case, we have both issue tracker to record a bug. 🙂

   If that model addresses the concerns you had in mind, I’m happy to turn the prototype into the smallest possible PR so you can review the actual maintenance footprint rather than committing to a larger design up front.

   ---

   Ok, to summarize what we have:

   • Isolated Maintenance & Zero Risk

     The Rust project lives in a separate repository managed by you, requiring only a minimal integration hook in python-semver. The pure-Python implementation remains the default, ensuring python-semver stays fully functional even if the Rust backend is abandoned.

   • Python as Source of Truth

     The Python implementation defines all parsing behavior and semantics. Automated CI in the Rust repository will continuously test against python-semver test suites and run differential corpus comparisons to detect divergence.

   • Zero Packaging Overhead

     Cross-platform native wheel creationand PyPI publishing will be fully automated in the backend repository. Core maintainers will not need to build, test, or manage native binaries.

   • Decoupled Releases

     Both projects maintain independent release schedules, meaning python-semver updates do not require synchronized Rust releases unless parser contracts change.

   • Immediate Next Steps

     You propose submitting a minimal pull request so maintainers can evaluate the footprint of the code changes before making any formal commitments.

   Is that correct? If yes, then let's make it possible! 😁
4. lowmiaq-gmail commented on Sep 2, 2026

   

   lowmiaq-gmail

   on Sep 2, 2026

   ContributorAuthor

   More actions

   Hi Tom,

   Yes, that’s exactly right. Thanks for putting it together so clearly.

   I’ll go ahead and prepare a minimal PR next, so you can review the actual maintenance footprint without any larger design commitment up front.

   Just let me know if you’d like me to adjust anything before I open it.

   👍React with 👍1Reacted by Tom Schraitle
5. lowmiaq-gmail commented on Sep 2, 2026

   

   lowmiaq-gmail

   on Sep 2, 2026

   ContributorAuthor

   More actions

   Hi Tom,

   Minimal adapter PR is up for the footprint review:

   #476

   Happy to adjust the shape if anything looks heavier than you’d like.

   👍React with 👍1Reacted by Tom Schraitle
6. tomschr commented on Oct 5, 2026

   

   tomschr

   on Oct 5, 2026

   Member

   More actions

   Forgot to close this issue. This is all implemented in #476.
   Thanks!
7. tomschr

   closed this as completedon Oct 5, 2026