-----BEGIN PGP SIGNED MESSAGE-----
On 04/16/2011 11:55 AM, Sascha Welter wrote:
> (Fri, Apr 15, 2011 at 02:39:26PM +0200) Hanno Schlichting
>>> I assume this kind of thing has been discussed and the decision has been
>>> taken on judging backwards compatibility vs. the benefits of doing this?
>> The particular code was unused for several years,
> Sigh. Sorry Hanno, but just *sigh*.
> "Unused"? Unused by whom? There is code out there that uses stuff
> without you or anybody else typing in the code on a keyboard. How can
> you claim it's unused? Do you make audits on what pieces of code people
> use in their Zope projects?
> People want to be able to move an existing Zope app to a new server and
> a new Zope install there without having to sell the customer onto 15
> hours of maintenance coding to fix 100 things that break. Not every
> project is a new project.
>> using manage_*
>> methods is deprecated since Zope 2.8 or 2.9.
> You are wrong.
> CHANGES.txt in Zope 2.11 does not know anything about manage_*
> being deprecated. Instead it says:
> - Turned deprecation warnings for manage_afterAdd, manage_beforeDelete
> and manage_afterClone methods into discouraged warnings. These
> methods will not be removed in Zope 2.11, but stay for the
> foreseeable future. Using events is still highly encouraged.
> The CHANGES.txt from 2.12 says:
> "Downgrade the ``manage_* is discouraged. You should use event
> subscribers instead`` warnings to debug level logging. This particular
> warning hasn’t motivated anyone to actually change any code."
> And it will damn sure not motivate anybody, because code that uses that
> runs just fine (thank you) and nobody sees any need to "fix" it to use
> something that is undocumented and not tested in that particular setup.
> That's not how maintenance on a working system works.
> CHANGES.txt in 2.13 doesn't know anything about manage_* being
> deprecated or removed any further.
> If it doesn't break anything, if it doesn't break new code, why
> depreciate and why remove it? We've had this same game with zLOG and
> manage_afterAdd before. They're both still here, for good reason.
>> If you really need this code, just copy it from an old release into
>> your own codebase.
> How about you don't delete it and I don't have to add it back?
> Less work for you, less work for me, less work for everybody.
>> Developing with Zope 2 is probably a frustrating experience, but that
>> shouldn't come as a surprise to anyone.
> It comes as a surprise to me. In fact, I find developing with Zope 2
> quite an amusing and entertaining experience. And easy. You must be
> doing something wrong.
> I can understand though that Zope is not a system for newbies to start
> *right now*, OK.
>> The project is dead for
>> several years now and is only kept left alive while Plone is migrating
>> away from it or some long time developers are still using it. It's a
>> large piece of legacy code that has no future - certainly not for new
>> users or developers not already familiar with it.
> Well, I don't know anything about what Plone is or isn't doing. No Plone
> was ever able to move to a different Zope version without rewriting
> basically everything, so maybe you think that's normal. It isn't like
> that for most everybody else though.
> IMHO the way to treat a "large piece of legacy code" is *not* to break
> various things inside it because some other idea to do things seemed so
> much cooler a while back (but which we also abandoned, because we'll get
> rid of it all anyway).
> The way to do that properly is to make it as stable an lasting as you
> can and let it stay alive till it falls over by itself. So if you think
> it's dead, OK, but there is no reason to actively kill it piece by piece.
Moving a "big old application" across multiple major versions at onece
of any platform is likely to be painful: even projects which are
careful about backward compatibility (Zope has historically been very
good at this) will have issued deprecation warnings in the versions you
skip. Your best bet would be to port the app stepwise to the latest
release of each major version, noting and fixing the warnings as you go.
Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13
includes lots of changes which *remove* functionality from Zope to
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (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 -