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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -