-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 05.07.2011 11:30, schrieb Martin Aspeli: > > > On 5 July 2011 10:18, Hanno Schlichting <ha...@hannosch.eu > <mailto:ha...@hannosch.eu>> wrote: > > On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli > <optilude+li...@gmail.com <mailto:optilude%2bli...@gmail.com>> wrote: > > I would've thought it would also be possible for those who rely on > this to > > maintain the relevant eggs as optional installations against Zope > 2.x, no? > > The ZMI is not a package - we don't have a split into zope and > zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates > stops using RestrictedPython and the OFS base classes don't inherit > from Acquisition.Implicit anymore, it'll be really hard to keep the > legacy development approach working. > > > I think it might be useful to spell out the reasons behind this (here, > or better yet, somewhere more permanent like zope.org > <http://zope.org>). I can imagine people reading this and wondering why > it's a good idea, especially those who have an investment in the > existing technologies. > > > Someone might try, but I think it's not a wise decision to spent any > resources that way. At some point every application written in the > legacy style has to be rewritten. I think it would be a better use of > resources for anyone to start doing that than maintaining a dead-end. > > > 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.
I agree with Martin, that a sane upgrade path should be provided at least. If people still use things like DTML, the ZMI, etc., then it would be highly frustrating for them to simply drop these. You can split the components from the base and provide them as optional where possible. This seems to be possible with most of the components that Hanno listed as depreciated/to be removed soon. And most importantly: provide sane upgrade paths for depreciated components. If the ancient session management from Zope2 is to be dropped, tell people what they should use instead, and how to migrate their old_but_still_in_use applications/projects. Greetings, jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEudWAAoJEFJi5/9JEEn+jXcP/RyNZw1JFfPqG/nzacqAbx4F WdoZGyARkGVV1BTEtE6/cvkJCnHNuBgEaeAtGJY7h5HdqT781uKNdhJurncA8ii3 7RXm0CVJ1AZXdycDT0DoOMyYWBx345cglk5S+5bbfIdMWVvPNyDgQhIjFRT20jA7 cMi8e4mStgd2upwS487L+FubmkWyOw8d8bUbL+SFvykNOEXr6OqwTHLTBWh4yVi3 //zmV6T/wtmcpIyiqdx4VkdvmmttJbM2ro0FcIvO46XHD87XrYSiyEZM3XiYsjiF 8hNqhHtkiA/mLRXw6jIDhMvzvIsgKsWdHMmR2OOGVPY5nnWuvmBimaSj+u01TJIS K1MLMNnheTqH7alr7Mn0PmIGfbX4ED9DwzrR2yen6iHmWqgHShDC+OAFrRzFBK51 fPnLlAVQrQSDLPhhm+Ytv55o/hzmzARUUnta4d+Ac2k0y/DLXuz+8svSdfLuKVyv 0W5onVnLuXH5z5X3HM5ubywUdyfOaVgCIYdV+vVh9tQCeLZsDN6rVl+4H5WCQuNk J17+m4B59zAxAhIxa0ZwnLHVwO+GgP+pIHhQtSZGF1WY43wBFPDxKtt8xxBCjPvk LyMPgevwTn4rhETwkCsZFqMvVGBa/AmKX3suQhNBNFr+8qOy/H/q4tOQGpUyBmNE nVJtAfGh/G+ecROUKMAW =eItl -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )