[Catalog-sig] Stable-releases-only PyPi

Tres Seaver tseaver at palladion.com
Tue Jul 12 15:59:07 CEST 2011

Hash: SHA1

On 07/12/2011 09:25 AM, Éric Araujo wrote:
> Le 11/07/2011 18:45, Tres Seaver a écrit :
>> On 07/11/2011 08:41 AM, Éric Araujo wrote:
>>> I was under the impression that PEP 386 only defined the syntax 
>>> of version numbers and a comparison algo, but no semantics.  IOW 
>>> there is no way for a tool to know that 2.6.33 is devel and 
>>> 2.6.34 stable, or that 1.0.4 does not break compatibility with 
>>> 1.0.2, or anything else of the sort.
>> The PEP386 semantics are implied by the sorting order, where 
>> "final" (non-suffixed) releases sort higher than any suffixed 
>> releases except "post" releases.
> I’m aware of the algo for sorting and asserting final/non-final.  I 
> was talking about stability and compatibility policies: PEP 386, 
> contrary to the misnamed Semantic Versioning spec for example, does 
> not define anything in this regard (this was already pointed out a 
> few months ago by PJE, I think).  See the examples in the quoted
> text above.

Hmm?  In what sense would 2.6.33 ever be used for a "devel" release?
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.

If your point is that a "stable-only" mirror could still induce breakage
on projects which use it blindly, I certainly concur.  In fact, I have
long asserted that any "integrator" whose production builds uses PyPI
directly is solely responsible for the breakage, when (not if) it occurs.

- -- 
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Catalog-SIG mailing list