[Catalog-sig] Stable-releases-only PyPi
tseaver at palladion.com
Tue Jul 12 15:59:07 CEST 2011
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Catalog-SIG