-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2011 10:26 AM, Éric Araujo 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
That > would have been 2.3.36 vs. 2.2 29: the even / odd variation for development / stable was based on the minor release number, not the third. Also note that the kernel devs dropped that pattern quite a while back as being unfruitful. >> 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 *do* have a common base for expectations: the set of projects on PyPI which violate those expectations (about the semantics of the version number) is pretty small. Backward-[in]compatibility policy is just not a documented part of those expectations: you have to learn each project's policy about BBB issues as part of evaluating whether to use its releases. >> 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. Sure: blindly trusting any project / author is not a good idea for people who need highly-reliable / reproducible build-deployment solutions. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cYGMACgkQ+gerLs4ltQ6ThwCgn4j9GAf2Vm9TR8C9AQO6VLZ+ bE8AoLQsfXMYK0r3buANjMqegAbl8Lkt =xr3/ -----END PGP SIGNATURE----- _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
