On Wed, Dec 01, 2004 at 10:43:22AM -0500, Joe Schaefer wrote: > Stas Bekman <[EMAIL PROTECTED]> writes: > > > One needs to go through a deprecation cycle before any backwards > > compatibility in the same generation of the project can be dropped. > > Heh, a search for "deprecation cycle" on marc's [EMAIL PROTECTED] archives > comes up empty.
I'm not sure really what you expect. That no API changes can be made during 2.1 development unless they were predicted ahead of time by N years and marked with a red dot? 2.2 will not be backwards compatible with 2.0, that is documented in VERSIONING. Exactly *how* it is not compatible depends on exactly what gets changed. Exactly *what* gets changed depends on round tuits and itches getting scratched by individual developers. How can we predict that Mladen Turk will come along and do a bunch of proxy work ahead of time? Should we say instead to Mladen Turk "Hey, nice code. But we'll have to deprecate <this> and <that> - come back in three years when 2.3 opens and you can do your work then. Thanks for calling!". Formal process has its place, but I don't see it here. Regards, joe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
