[Catalog-sig] names vs. releases

Richard Jones richardjones at optushome.com.au
Wed Aug 27 10:36:37 EDT 2003


On Wed, 27 Aug 2003 12:06 am, Jeremy Hylton wrote:
> The current package index lists every release of as a separate item.  If
> a look at a set of packages, I will see separate entries for each
> release of a package.  I'm keenly aware of this, because I do a lot of
> ZODB releases; there are nine different entries with two different names
> in pypi.

This is what the "hide" flag on the releases is for (see the "tip of the week" 
on the front page that's been active for the last couple of months :)


> How hard would it be to collapse the nine ZODB entries into a two
> packages, one with eight releases and the other with one?

What criteria is used to determine which bucket the releases fall into? 
Currently ZODB has these releases:

ZODB3 3.1.2
ZODB3 3.1.2b1
ZODB3 3.1.2b2
ZODB3 3.1.3
ZODB3 3.2a0
ZODB3 3.2b1
ZODB3 3.2b2
ZODB3 3.3a1

So from my guessing, there's a stable release (3.1.3) and two development 
releases (3.2b2 and 3.3a1) currently active.


> It seems more 
> useful to have a single entry for each package, and let users drill down
> if they want to see different releases.  I expect most users will just
> want the most recent release.

As partially demonstrated above, the problem is that it's hard for a program 
to know what the "most recent release" is, especially when a project has 
stable and unstable branches both producing releases.

I *think* you're advocating not to show any version information at the front 
page, and to suck up the information from the "most recent release"? PyPI 
uses distutils' version number sorting code, but do you want to see the 
package with the highest version number, or the one that was updated most 
recently? Modifying the interface to do this would be a bit of work, and 
assuming we have a consensus on "most recent release" then I'd be happy to 
accept a patch (project members welcome :)


    Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20030827/ededa250/attachment.bin


More information about the Catalog-sig mailing list