[Zope-dev] deprecating the deprecation system?

[Lennart Regebro]

On Thu, Mar 5, 2009 at 17:35, Martijn Faassen <faassen at startifact.com> wrote:
> * I've had good experience in the Grok project with just noting changes
> that might break code in the upgrade notes for Grok and telling people
> how to fix it. Using documentation more background can be provided and
> it can become a lot more clear what to do.

True, but Grok-users will, thanks to it's new pre-1.0 status be more
prepared for changes. Just an observation...


I don't really have an opinion on the actual question. But I will talk
out loud here:

I think the goal, allowing third-party modules to support at least two
versions of the framework at once, where commendable, but it may very
well be that the work this caused was more than what it would be have
been to support several versions by conditional imports etc in the
third-party modules.

On the other hand, if you have say, Zope 3.4 depends on zope.foobar
3.4.x, and you in zope.foobar 3.5.0 make a BBB-breaking refactoring
without deprecation,  and you then in 3.5.1 introduce a new, unrelated
feature, it means you can't use that new feature in Grok while Grok
still depends on Zope 3.4, which is a shame. But maybe not a problem.
Deprecating would allow you to do that.

It's probably an impossible task to have both backwards compatibility
and still have innovation without loads of old cruft in the code. It
becomes a balancing act. I don't know where to put that balance. Maybe
we could have deprecation but for much shorter time. Say, between
releases of the framework? Or we could simply not deprecate, but
encourage backwards compatibilities, at least until a new major
version is released of the framework?

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64