[Zope3-dev] A thought on backward compatibility and minimum
versions
Jim Fulton
jim at zope.com
Thu May 31 15:09:43 EDT 2007
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:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Zope3-dev
mailing list