Paul Moore

> Can one of the maintainers explain the logic here? It appears that the logic is [here](https://github.com/pypa/packaging/blob/main/src/packaging/specifiers.py#L257) - only *inclusive* operators count as "explicitly requesting" a pre-release, so `>1.1.0a1` does...

> Yes, this was prompted by https://github.com/pypa/packaging/issues/760, because a specifier like >1.0,

No, it's *precisely* in scope of what I'm thinking about. And the result *is* expressible as a specifier set (after all, ">0,

> I don't remember thinking to hard about it, and just did the ones that explicitly included the pre-release that was being mentioned, which meant that > and < were...

I guess a fair question for the `packaging` maintainers is whether they (you) would support a breaking change that did just that - made prereleases just like any other version,...

It means that I want to be able to parse metadata with (for example) legacy versions and *not* have an InvalidVersion error raised, but instead get the value as a...

To the list of "things that are not correct but may not be a problem", can I add * Invalid values (e.g., incorrectly formatted specifiers) in *any* field, when you're...

> Fair enough, but the exceptions would still cause you to have access to the invalid data via their raw strings. Maybe. But my core use case looks something like...

> This would cover both use cases, at the cost of an additional layer of indirection which is necessary to deal with the two sets of user needs here. That...

Thanks @dstufft - this is exactly the model I've been arguing for all along (and I agree, conversion to metadata should always raise - which I think is what @brettcannon...