--On 16. Juni 2006 09:12:36 +0100 Chris Withers <[EMAIL PROTECTED]> wrote:
Even numbered releases are "feature add" releases: 2.12.0 - "okay, lets start adding features" 2.12.1 - "whoops, fixed bug x" 2.12.2 - "added feature y" 2.12.3 - "whoops, fixed bug z" 2.12.0 - "added feature z" 2.14.1 - "whoops, fixed bug a" Odd numbered releases are "stable" releases: 2.13.0 - "we're happy that all features up to y are stable" 2.13.1 - "whoops, fixed bug z" 2.13.2 - "whoops, fixed bug a"
-10 I don't know what that model should solve?We must distinguish between the deprecation period for feature and the maintenance period of release. Both a currently one year. I have no problem with supporting releases for longer than one yr. In practice it is no big effort to apply patches too older branches as well (e.g. to keep 2.8 longer alive)...I think we *should* support older branches for longer than one yr since Zope 2 is used in large installatioins and ppl expect a certain amount of maintenance over a period of time. I see little reason not to fulfill this requirement..making a bugfix release from time to time is not really the problem. As an example a lot of Plone 2.1 site run on Zope 2.8 and we should support Zope 2.8 in a reasonable way as long as necessary (basically
until Plone 2.5 on Zope 2.9 is adopted by most sites). U My recommendation: 1 yr deprecation period as it is now 1 yr + X maintenance period for older branches. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
pgpmHAdorXfkL.pgp
Description: PGP signature
_______________________________________________ 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 )
