[Catalog-sig] Stable-releases-only PyPi
Tres Seaver
tseaver at palladion.com
Tue Jul 12 16:55:31 CEST 2011
-----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 tseaver at palladion.com
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-----
More information about the Catalog-SIG
mailing list