Martijn Faassen wrote:
Given the momentary confusion surrounding the release of a broken
package. By broken package in this case I mean something which seriously
breaks many many Zope 3 installations in an obvious way.
I think it might be wise to start working out some procedure surrounding
such a situation.
The procedure that appeals most to me is for buildout to be modified to
prefer "release" eggs by default (the work for this has been done, and
should be released soon).
I also recommend projects nail their version requirements so that no
matter what someone releases, they will be unaffected. This is how we
run the projects I'm involved in, and it helps that we can decide, on
occasion, to pay off our version debt all at once, and not have someone
else create emergency work for us.
* if a package is broken, the preferred route is to upload a new, fixed
package with a later version number as soon as possible. (incidentally,
it appears wise to verify manually that the new egg is indeed there by
checking the download server.)
+1
I'd therefore suggest that *if* we can't release a fixed egg for
logistical reasons within a brief time-period, we proceed to remove the
broken egg from the server and post a message to the mailing list saying
it's broken.
If buildout prefers "release" eggs, then only bad release eggs will
cause the above problem. Coupled with nailed versions, there should be
no reason for emergency communication or egg deletion. Having said
that, I don't abhor the idea of an occasional purge of a bad,
non-release egg.
--
Benji York
Senior Software Engineer
Zope Corporation
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
