Stephan Richter wrote:
> Updgrading to 1.3.x might not be easy for various reasons that I 
> think most of us experienced (I know I did). Releasing a new 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 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. 


> There is a compromise I am willing to take. If package depends on a 
> *new feature* or *feature change* in 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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to