Stephan Richter wrote:
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.
If a fix is possible, and someone backports it, a release should be made. If person B does not have access, there's nothing stopping them cutting their own egg and putting it up on their own egg server. I know I've had to do this before for packages like xlrd, which often have development but are extremely rarely released, and have maintainers who don't care about eggs at all.
Also expecting person B to create new releases for all packages where the bug fix would work is unrealistic.
Indeed, they only need to create releases for things they care about, it's the open source way :-)
I also don't recall open requirements bringing development to a halt?
They did. :-)
I'd love to see some actualy evidence of that ;-)
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 together.
I think we have seen this is a no-go.
Oh?
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. ;-)
I'm -1 on this compromise. If a package needs a bugfix of another package to work, then it should specify it. However, I *am* -1 on specifying a later version of a package just because it's available ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk