On Aug 4, 2008, at 12:37 AM, Aaron Lehmann wrote:
On Aug 2, 2008, at 11:45 AM, Chris Withers wrote:
Benji York wrote:
In case anybody's wondering how this complies with our "no
removal of any
release whatsoever" policy [1], be assured that a 3.4dev-r73090
thing isn't
a release by our standards. This version number not only
contains the 'dev'
marker, meaning it must have come from a development branch
(possibly the
trunk), it also contains the -rXXX suffix meaning it was made
right from a
subversion checkout without having created a tags first (why
else would you
want to include the revision number).
Still, it's likely that someone was using it and their buildouts
are now
broken. We should have instead generated a proper release with a
higher
version number and left the dev release alone.
This is silly.
Mistakes happen. Buildout and/or setuptools should be tolerant of
accidental releases that are then removed from PyPI.
What currently happens in cases like this?
If the buildout is nailed to that version or above, and there is
none, it breaks. Worse, if someone now adds another egg of the
same version, but consumers have cached a version, their buildout
won't download it, because it will already have that version in
cache. I realize that this particular compound error is unlikely
to happen in this instance, but the principle holds.
Yes, mistakes happen. What Benji is saying is that deletion is not
the right way to remedy them, as unintuitive as that may seem.
I do agree that easy_install behavior is pretty insane wrt preferring
dev releases over stable "old" releases. But I think it's pretty
reasonable to delete accidental releases, whatever the behavior of
setuptools/easy_install/buildout.
In the first case you mention where "buildout is nailed to that
version or above", that would have to be in error, as the release
shouldn't have been made in the first place. That also seems true of
the second case, but I suppose the difference is the offended person
is more innocent there: they should likely contact the person who
released it and ask them to not do that again.
- C
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
