> 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.) > 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. And even when the Trove classifiers are set, blindly trusting them would not be a good idea. Regards _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
