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
> 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. ;-)
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 ;-)
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -