[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