On May 31, 2007, at 2:08 PM, Dieter Maurer wrote:

Jim Fulton wrote at 2007-5-31 10:12 -0400:

In thinking about how we might specify that we want to depend on
major versions but sometimes need to specify minimum versions, the
following occurred to me:

- Suppose that we always had access to the latest released version,

- Suppose that, within a major release, all releases were backward

Then I assert that there is no *need* to specify a minimum release
within a major release.

I fear my colleagues responsible to maintain the productive versions
would not be happy:

  They want the system to be as stable as possible.

  If they need to introduce a new component, they usually
  prefer to just add this one component. Only if this forces
  other updates, they reluctantly will make them.

The motivation for this behaviour: even if a newer version
is supposed to be backward compatible, it often has slightly different
behaviour which may trigger bugs in the other parts of a complex system.

I agree, but this control should occur at at a different place. I suggest that when deploying or releasing an application or system, you want to fix all of the versions so that a released or deployed configuration is repeatable and so that changes are introduced in a controlled way. This can be done in a number of ways. You can have an application meta-package that specifies all of the versions, or, if you are using buildout, you can use buildout's facilities for fixing versions.

For individual reusable "library packages", you want to make the dependencies as non-restrictive as possible so as to maximize flexibility and reusability.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to