On May 31, 2007, at 2:47 PM, Dieter Maurer wrote:
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
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.
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 think a ' is missing above. I assume you mean that B requires "A
<=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....
Sure. For example, then A doesn't follow the rules and people will
have to use an inconvenient specification for it. This will often be
the case for non-Zope packages. For example, if Python was a
distribution, it would, sadly, have this property.
Now assume we want to install module "C" which needs "A" in version
"M.*".
Given the backward-compatibility policy of A, C's author has made an
error.
If "M.*" implicitly means: the newest minor release in the "M" series,
then "C" cannot be installed in the hypothetical system.
It means that any version of A in the M series should work. It
doesn't mean that the latest is required. If the requirements of the
"system" listed B before listing C, then a version of A compatible
with B would get used and that would also work with C.
If, on the other hand, if C is listed before B, then, using the
current setuptools algorithm, the latest version of A will be used
and will be incompatible with B. (Eventually, we'll switch to a
better algorithm.)
If, on the other hand, the dependency is expressed by "A >=M.m, <=
M.9999",
then "C" can be installed.
Assuming that this is C's dependency, it doesn't make any
difference. If C is named before B, you'll still get a version
conflict.
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.
That's exactly what I meant. In fact, I meant exactly what I said,
which was that:
"project_name V.*" would be equivalent to "project_name >=V, <V.
99999"
:)
Even for me "M.*" is nicer than "M.99999".
More importantly, IMO, "A M.*" is nicer than "A >=M, <M.99999".
I also think that:
"A M" is nicer than "A M.*".
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
