bad "zope.size" to remove from PyPI
Hi, could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090 This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211) Christophe
Christophe Combelles wrote:
could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090
This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211)
Done. 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). [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-softwar...
On Fri, Aug 1, 2008 at 7:03 PM, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Christophe Combelles wrote:
could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090
This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211)
Done.
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. -- Benji York Senior Software Engineer Zope Corporation
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? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
El 2 Aug 2008, a las 17:45 , Chris Withers escribió:
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?
Nothing. It's only a problem if somebody pinned zope.size version to 3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO because it's clearly not a release.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
El 2 Aug 2008, a las 17:45 , Chris Withers escribió:
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?
Nothing. It's only a problem if somebody pinned zope.size version to 3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO because it's clearly not a release.
We ought to look at yanking PyPI privileges for anybody who is pushing such eggs out. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlLRY+gerLs4ltQ4RAieGAKDaDX6HX+xZZMA4sVGX6YbpoCVFLQCfW5gY 4AZZlvIHyyTx2uGZvJrYp8E= =WSJT -----END PGP SIGNATURE-----
Philipp von Weitershausen wrote:
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?
Nothing.
Well, that wouldn't be good... In what situations would buildout or setuptools pick 3.4dev-r73090? If it has been picked, what happens when that package is updated by either tool? What *should* happen is the latest package still on pypi gets picked and replaces 3.4dev-r73090, maybe with a warning issued if necessary. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Sat, Aug 2, 2008 at 9:27 AM, Benji York <benji@zope.com> wrote:
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.
Yes. It would be even better if PyPI refused registrations of dev versions. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Sat, Aug 02, 2008 at 05:23:14PM -0400, Fred Drake wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Benji York <benji@zope.com> wrote:
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.
Yes.
It would be even better if PyPI refused registrations of dev versions.
That would be good. What I don't understand about this thread is why 3.4dev was "newer" than 3.4.0. Doesn't PyPi use the same versioning rules as setuptools? $ python Python 2.5.2 (r252:60911, Jul 20 2008, 01:20:16) [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. f>>> from pkg_resources import parse_version
parse_version('3.4dev-r73090') < parse_version('3.4.0') True
So what exactly was the problem? -- Paul Winkler http://www.slinkp.com
participants (7)
-
Benji York -
Chris Withers -
Christophe Combelles -
Fred Drake -
Paul Winkler -
Philipp von Weitershausen -
Tres Seaver