[Zope3-dev] A thought on backward compatibility and minimum versions

[Jim Fulton]

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