On Tue, Jul 12, 2011 at 4:26 PM, Éric Araujo <[email protected]> wrote: >> Hmm? In what sense would 2.6.33 ever be used for a "devel" release? > > By the linux kernel project, for example: > http://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases > >> If my application got broken by a project that made such a release, I >> would be busy ripping out a dependency produced by such an unreliable >> project, not arguing whether PyPI could / should implement some >> "technical measure" to make everything happy. > > Granted, this linux kernel versioning example was extreme. However, > compatibility issues between X.Y.Z and X.Y.Z+1 is not unheard of, and > that’s a problem that PEP 386 does not address. (Even if it did, > nothing would prevent human error or malice, we’d still need human > checks, but at least we’d have a common base for expectations.)
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. There's no difference here between a trove classifier and a version scheme. Those are just conventions, flags. So I am not sure how you want to address this issue exactly, a dev marker is a dev marker... and dev/non-dev != stability for backward compat issues, it's a problem to be addressed at the project level, with its own conventions. > >> If your point is that a "stable-only" mirror could still induce breakage >> on projects which use it blindly, I certainly concur. > > My point is that “stability” is not defined, at least not by PEP 386. 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 up to every project to define stability, and I agree that the Trove is a good way to do it. > And even when the Trove classifiers are set, blindly trusting them would > not be a good idea. Ah you lost me here. If the project uses a trove classifier to mark "stable", either you trust the project either you don't. Deciding if you upgrade to the newer version in your environment is your own problem and orthogonal > > Regards > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig > -- Tarek Ziadé | http://ziade.org _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
