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


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

Reply via email to