Wichert Akkerman wrote: > Previously Martijn Faassen wrote: > >> Hey, >> >> Stephan Richter wrote: >> [snip] >> >>> There is a compromise I am willing to take. If package zope.bar depends on >>> a >>> *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 >>> version >>> 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. > > Wichert. > > 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 case-by-case basis. Jacob _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )