[Zope-dev] direction

[Jonas Meurer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.07.2011 11:30, schrieb Martin Aspeli:
> 
> 
> On 5 July 2011 10:18, Hanno Schlichting <hanno at hannosch.eu
> <mailto:hanno at hannosch.eu>> wrote:
> 
>     On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli
>     <optilude+lists at gmail.com <mailto:optilude%2Blists at 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-----