On Monday 16 March 2009, Martijn Faassen wrote:
> I'm not sure I agree you here, Stephan. A possible disagreement within
> the steering group, how interesting! :)
> The most widely open requirement is this:
> but another open requirement is this:
> zope.foo >= 1.3
Sure, but here is what happened before.
Person A made a bugfix to zope.foo 1.3, releasing zope.foo 1.3.1. He then
said, ok, zope.bar 1.0.0 depends on zope.foo >= 1.3.1. Person B backports the
bug fix to zope.foo 1.2.1. Now zope.bar would also work with 1.2.1, but can't
because of the version specification. So person B has the choice of upgrading
to zope.foo 1.3.x or release a new version of zope.bar.
Updgrading to zope.foo 1.3.x might not be easy for various reasons that I
think most of us experienced (I know I did). Releasing a new zope.bar version
might not be possible, if person B does not have access. Also expecting
person B to create new releases for all packages where the bug fix would work
> I also don't recall open requirements bringing development to a halt?
They did. :-)
> You bring up the case of backporting a fix (a relatively rare
> occurrence, but it certainly happens):
Not so rare at all, I think.
> Updating that in all packages that depend on zope.foo 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
I think we have seen this is a no-go.
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. ;-)
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -