Jim Fulton wrote at 2007-5-31 14:15 -0400:
>> 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
>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
>For individual reusable "library packages", you want to make the
>dependencies as non-restrictive as possible so as to maximize
>flexibility and reusability.
I agree but not to specify a minimal version and instead to assume
that always the latest release version must be used does not
maximize but reduce reusablitity.
Look at the following szenario:
In a given system module "A" is installed in version "M.m".
For some reason, another module "B" in the system cannot work with
"A" in any version "M.m'" with "m' > m".
I know that this violates your assumption that any newer minor release
is compatible with any older one (in the same major release).
Unfortunately, such things happen....
Now assume we want to install module "C" which needs "A" in version
If "M.*" implicitly means: the newest minor release in the "M" series,
then "C" cannot be installed in the hypothetical system.
If, on the other hand, the dependency is expressed by "A >=M.m, <= M.9999",
then "C" can be installed.
If your suppositions are only a form of introduction for the "M.*" syntax
(or "M*", if you prefer) but does not affect the semantics of "M.*",
i.e. if "M.*" means 'needs the module in *any* "M" version',
then I have no objections.
Even for me "M.*" is nicer than "M.99999".
Zope3-dev mailing list