[Catalog-sig] Stable-releases-only PyPi

[Ben Finney]

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
requires.

> 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
> feedback.

It's also not at all required under PEP 386 for any project to use those
markers.

> 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
project.

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_ |
_o__)                                                                  |
Ben Finney