Tarek Ziadé <ziade.ta...@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 _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
