Wichert Akkerman wrote:
> Previously Martijn Faassen wrote:
>> Stephan Richter wrote:
>>> There is a compromise I am willing to take. If package zope.bar depends on
>>> *new feature* or *feature change* in zope.foo 1.3.x, then it should specify
>>> the version. In other words specifying open restrictions on the major
>>> levels is okay, but never on the bug fix level. (I just hope this does not
>>> bite us later. ;-)
>> Yes, I was thinking in this direction too. I can see this as more of an
>> issue with bug fixes than with feature changes. This means that
>> requirements can only say zope.foo >= x.y, and never zope.foo >= x.y.z.
>> What do people think?
> -1 still
> If I install a package I want to have a guarantee all aspects of that
> package work correctly. With this compromise that is not possible.
I am not quite sure what you mean... Are you saying that the proposal
does not go far enough, and we should allow the full >=x.y.z? Or are you
against any and all versions in setup.py?
I think the best policy is to use versions specs for base packages
(minimum, as well as maximum), but only when it is *known* that not
meeting the requirements means the derived package is useless. This is
most likely to happen when the API of the base package is changed (which
is only allowed in a major version), but could in rare cases happen for
other reasons. To me the important thing is not the major/minor version
distinction, but rather the degree of uselessness.
Of course there may be broad guidelines such as "only use major
versions", but the way I see it this really calls for a decision on a
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -