Re: [Zope-dev] Time-based releases vs Bugfixing
Lennart Regebro wrote: Only because we have more stable releases, only? That's the big problem here ;-) 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. And the difference is that this didn't happen very often during 2.6 to 2.8, because there were no new features to _need_. That's not a good thing. Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death. I'm not sure I agree. Feature complete and stable is where most frameworks want to be. I'd suggest that constant churn and _need_ for upgrades is the way to ultimately die ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Time-based releases vs Bugfixing
Wichert Akkerman wrote: Previously Max M wrote: Andreas Jung wrote: At some point you have to make a cut to get rid of old crap. Fixing the zLOG issue is a straight forward approach with very little risks for the programmer and it won't take too much time..I don't see a major problem with that. Except that it hits a sore spot for open source right on the head. Products are developed for our customers, and they will keep working for those customers until they choose to upgrade. But until then you don't upgrade and the changes made in later Zope versions are not relevant. If and when you do an upgrade you will have update your products to reflect that Zope (and other products) have evolved. That will always be true for upgrades. Okay, 2 point: 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. 2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases vs Bugfixing
On 6/15/06, Chris Withers [EMAIL PROTECTED] wrote: 2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse. Only because we have more stable releases, now than we had during 2002-2005. That in turn was because the development effort was directed at Zope3 during this period. Before that, we has stable releases around twice a year too: Between 2.1 and 2.2 there was 225 days Between 2.2 and 2.3 there was 196 days Between 2.3 and 2.4 there was 178 days Between 2.4 and 2.5 there was 186 days Between 2.5 and 2.6 there was 266 days All pretty much once every six months. What happened then, during 2.6 to 2.8 was that the development of Zope was done on Zope3, and Zope2 development suffered from this. So this is not a fault of time based releases. The difference is this: 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. And the difference is that this didn't happen very often during 2.6 to 2.8, because there were no new features to _need_. That's not a good thing. Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
