publishing plans?

[shmillery]

Is there any plan to publish this project? I'd like to use it as a dependency, but it appears this has not been published to crates.io

[Eh2406]

This was developed against the (at the time) unreleased version of pubgrub. It was actively being developed and worked on as part of my work responsibilities. Then work changed its priorities and I did not make significant progress. The other pubgrub contributors managed to release 0.3, with the new API required for this project. But I continue to not have more time, or personal attention, to make the changes here and polish for a crates.io release. After continued frustrations, I cut ties with my employer. I am currently taking a hiatus from technical contributions in an attempt to recover from the associated burnout.

I would love to hear more about how you're hoping to use the project? How much bug fixing and maintenance would you be hoping I could provide? Or on the other hand would you be interested in upstreaming any fixes you need to create? Helping a creator work on a cool new project is exactly the kind of thing that might get me to do an initial release.

[shmillery]

Completely understandable about being burned out. I am using this in my tool here which is a simple git package-like management tool, called gipm, where this repo provides the bridge between semver and pubgrub. For now I have copied this into my source tree to allow me to publish an initial version which you can see here; your repo here worked out of the box for me with a git dependency and I only made minor modifications to bring it into my source tree to facilitate publishing my project onto crates.io.

To be frank, I don't know if my tool will get any traction but I have enjoyed working on a new project. As far as your support I'd envision this to be minimal but accept/review pull requests and publishing new versions if changes are identified. Since my project is quite small I understand that it may be easier to just continue as is for the time being - but this could maybe benefit other users someday.

[Eh2406]

Most of the complexity of this project is caused by trying to exactly model the existing (frankly bizarre) semantics dictated by cargo of the interactions between version requirements (^, >, ~, ect.) and prerelease versions (-beta). If your project is not have to match the semantics of an existing ecosystem, I would choose something significantly simpler. (The https://github.com/pubgrub-rs/semver-pubgrub/tree/new-pre-release Is a throwaway branch for experimenting with alternative simpler semantics.)

For example, have the requirements match prereleases the same way they match normal releases. Of course you do want some pressure to keep prereleases opt in. So I would pair the simpler semantics with a separate mechanism, like making the root project individually list all prereleases they're willing to trust. I believe this is what the uv project did. You could ask them for advice about how well it worked.

Another alternative that leaves your options open is to "just" band pre-release versions entirely. Then you only need to define these exact semantics when you actually make prerelease available at all.

With that caveat put in place, I'm happy to help however I can. If you find ways to improve this library I would be happy to merge them in. If publishing the library with cargo semantics would be helpful, I will find the energy to do that. If you have questions or just want to chat, I hold office hours every Wednesday. Absolutely let me know how I can help!