[Catalog-sig] Stable-releases-only PyPi

Tarek Ziadé ziade.tarek at gmail.com
Tue Jul 12 16:44:57 CEST 2011


On Tue, Jul 12, 2011 at 4:26 PM, Éric Araujo <merwok at netwok.org> 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
>
>> 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 provide a versionning scheme with a dev tag to be used for dev
releases, if people push a dev version under a version number without
the dev flag, that's their fault.

There's no difference here between a trove classifier and a version
scheme. Those are just conventions, flags.

So I am not sure how you want to address this issue exactly, a dev
marker is a dev marker... and dev/non-dev != stability

for backward compat issues, it's a problem to be addressed at the
project level, with its own conventions.


>
>> 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.

You can't define what stability means in a generic way in the
versionning scheme.  We have dev marker, beta alpa, rc markers but
that's just transitional states between dev and prod for the sake of
feedback.

It's up to every project to define stability, and I agree that the
Trove is a good way to do it.


> And even when the Trove classifiers are set, blindly trusting them would
> not be a good idea.

Ah you lost me here. If the project uses a trove classifier to mark
"stable", either you trust the project either you don't.  Deciding if
you upgrade to the newer version in your environment is your own
problem and orthogonal

>
> Regards
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>



-- 
Tarek Ziadé | http://ziade.org


More information about the Catalog-SIG mailing list