[Catalog-sig] Stable-releases-only PyPi
ben+python at benfinney.id.au
Wed Jul 13 00:02:40 CEST 2011
Tarek Ziadé <ziade.tarek at gmail.com> writes:
> We provide a versionning scheme with a dev tag to be used for dev
> releases, if people push a dev version under a version number without
> the dev flag, that's their fault.
How is it a “fault”? It's up to the project to decide the semantics of
their version strings.
If PEP 386 is going to be used as a blunt instrument to force semantics
(and I agree with Eric that its poorly-chosen name encourages this),
then the fault of that is with those who misunderstand what PEP 386
> for backward compat issues, it's a problem to be addressed at the
> project level, with its own conventions.
Yes, thank you. Let's stop saying “fault” if a project's chosen meaning
for version strings doesn't require words in version strings.
> You can't define what stability means in a generic way in the
> versionning scheme. We have dev marker, beta alpa, rc markers but
> that's just transitional states between dev and prod for the sake of
It's also not at all required under PEP 386 for any project to use those
> It's up to every project to define stability, and I agree that the
> Trove is a good way to do it.
Yet there seems to be no Trove classifier for the stability of an
individual version, as contrasted with the “overall stability” of the
Should we re-purpose that trove classifier to this meaning? Maybe. But
how to convince everyone to use it that way?
\ “First things first, but not necessarily in that order.” —The |
`\ Doctor, _Doctor Who_ |
More information about the Catalog-SIG