support for prereleases

[jlgerber]

Is the plan for handling prereleases? The example version::SemanticVersion does not currently support pre-releases at all.

It seems that the major challenge with prereleases -- the one worth taking into account because it would affect the design in general -- is that an end user will want to be able to influence the solve to ignore pre-releases entirely via the solver method. There doesn't seem to be an affordance for that currently.

Or am I thinking about this incorrectly? Is this really the responsibility of the DependencyProvider?

[Eh2406]

It is definitely a problem, and one we have bean thinking about. ( cc #78 (comment) and pubgrub-rs/advanced_dependency_providers#3 and #49 and dtolnay/semver#223 ). If you want to "solve without using prereleases versions" then you can customize your DependencyProvider to filter them out of consideration. Similarly, if you want to have a "global list of prereleases to allow" that is also not hard to do with a custom DependencyProvider. Where things brake down is if you want to have some "Constraints" that allow prereleases and others that do not. I think that will require the ability to customize the representation of "Constraints", but I am still figuring out what that would look like. The working prototype, still in need of a lot of polish and documentation is at range-trait branch and being discussed at zulip. Feel free to pick up that work and take it for a spin. An example of it being useful would be invaluable!

[lpil]

Hello! I'm very interested in this as well

For my use case I wish to be able to include prereleases for the same version only if the specified upper/lower bound includes a prerelease. For example > 1.0.0 and <= 2.0.0-rc1 accepts 1.9.0 and 2.0.0-rc1 but not 2.00-rc2 or 2.0.0, while > 1.0.0 and <= 2.0.0 accepts 1.9.0 and 2.0.0 but no prereleases such as 2.00-rc1.

Thank you

[Eh2406]

I have a proof of concept implementation of support for the Semver crate, with one of the draft branches for 0.3. It should have the semantics @lpil needs.
The code is at: https://gist.github.com/Eh2406/88b8c799be3f3a6589073e8e58504a11
I think the concept can be extended to where a version needs different requirements depending on witch of a small number of categories it is in. (in my case pre-release or not).

[lpil]

Wonderful, thank you @Eh2406. I look forward to the release of 0.3!

[mpizenberg]

Hey @jlgerber and @lpil , we just released a new section in the guide about pubgrub's limitations and how to circumvent some of these. I hope it explains clearly what are the different challenges (including for pre-releases) and how it can shape future APIs for pubgrub and people trying to use it.

[lpil]

Thank you for the update and for the excellent documentation!

[mpizenberg]

Hi all, this is just to inform you that prereleases will be supported with the new API provided by v0.3 of pubgrub, currently already landed in the dev branch. We still need to work on documentation and example usage though so it will take few weeks / couple months until the release is done. I'll close this issue and suggest that you subscribe to releases of this repo to be reminded when that happens.