Stephan Richter wrote:
> On Sunday 15 March 2009, Wichert Akkerman wrote:
>> If the package does not work with an older version of zope.publisher
>> than imho that version restriction *has* to be in
> And what if I backport the fix?
> We have done version specification like this in the Zope packages before and 
> it almost brought development to complete halt, because versions would not 
> match anymore.

I'm not sure I agree you here, Stephan. A possible disagreement within 
the steering group, how interesting! :)

I agree we should never hardcode version requirements in that 
limit the usable version to only one or a few selected ones.

The version requirements in should always be "open".

The most widely open requirement is this:

but another open requirement is this: >= 1.3

I also don't recall open requirements bringing development to a halt?

I think more specific open requirements (as opposed to the most widely 
open requirement) can be very useful. Useful to the maintainers of the 
Zope Framework KGS, the Zope 3 KGS, the Grok KGS, the Zope 2 KGS, and to 
application specific lists of packages, and users who are developing or 
testing packages in some other way. I've used this pattern quite 
successfully when developing a bunch of related packages.

You bring up the case of backporting a fix (a relatively rare 
occurrence, but it certainly happens):

So, 3.2 says it needs >= 1.3.

Now you take something from 1.3 and also put it in 
1.2.3 and onwards. could now work with 1.2 too, and it 
doesn't declare that it does.

You could release a new minor version of 3.2.1 that has a wider 
specification (if I get the spelling right): >= 1.3, >= 1.2.3

(I'm not sure whether setuptools will consider this an "adjacent 
redundant condition and resolve this to >= 1.2.3..)

Updating that in all packages that depend on for just that 
feature is indeed a bit of a burden. It does make it more likely that 
when someone does an update they'll get a set of package that work together.




Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to