<br><br><div class="gmail_quote">On 5 July 2011 10:18, Hanno Schlichting <span dir="ltr"><<a href="mailto:hanno@hannosch.eu">hanno@hannosch.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <<a href="mailto:optilude%2Blists@gmail.com">optilude+lists@gmail.com</a>> wrote:<br>
> I would've thought it would also be possible for those who rely on this to<br>
> maintain the relevant eggs as optional installations against Zope 2.x, no?<br>
<br>
</div>The ZMI is not a package - we don't have a split into zope and<br>
zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates<br>
stops using RestrictedPython and the OFS base classes don't inherit<br>
from Acquisition.Implicit anymore, it'll be really hard to keep the<br>
legacy development approach working.<br></blockquote><div><br></div><div>I think it might be useful to spell out the reasons behind this (here, or better yet, somewhere more permanent like <a href="http://zope.org">zope.org</a>). I can imagine people reading this and wondering why it's a good idea, especially those who have an investment in the existing technologies.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Someone might try, but I think it's not a wise decision to spent any<br>
resources that way. At some point every application written in the<br>
legacy style has to be rewritten. I think it would be a better use of<br>
resources for anyone to start doing that than maintaining a dead-end.</blockquote><div><br></div><div>This is a pretty sweeping statement that I think could cause a lot of nervousness. It might be the right thing in many ways, but we need to at least provide a bit more context. If you're a business that's invested dozens of person-years into a product, the prospect of rewriting could seem fairly daunting. At least we, as the Zope 2 community, need to set out the case for change and some kind of idea of timing and transition path, even if that means in some cases getting to a "long term maintenance" release and in other cases evolving away from certain technologies whilst being confident to keep using others.</div>
<div><br></div><div>Martin </div></div>