-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -