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, 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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to