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
compatible,
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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
