Chris Withers wrote: > Adam GROSZER wrote: >> Someone releases a new package version and your project just break the >> next day. That's a nightmare. > > That shouldn't happen with individual package releases where releases > are done sensibly. > (ie: if you're going to do a big backwards-incompatible release, let > people know. If you rely on a package, put in some sensible version > constraints in your setup.py, if your *project* (rather than your > packages) is paranoid (and it should be!) then lock the versions you use > down in something project-specific like a buildout.cfg, if you use buildout.
The community can give suggestions about locking down. this is not some kind of fancy theory but something that has worked for Zope 3 and Grok since late 2007. One of the things wrong with the zope-dev community is that we way too heavily in favor of the "here's a giant toolbox, just figure it out" attitude in the name of ultimate flexibility. Instead we have to think about ways to figure out things *for* people so they don't have to do a lot of duplicate work. We should of course still support the giant toolbox use case. I'm just saying we should do *more* than that, too. Regards, Martijn _______________________________________________ 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 )