[Zope-dev] Time-based releases a good idea?

[Andreas Jung]

--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <chrism at plope.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Warning: This is gonna be ranty and will almost certainly contain  foul
> language. ;-)

You're allowed to do so :-)

>
> There was a message sent to the list about deprecating zLOG on  January 8
> of this year by Andreas, but it was supposed to have been  deprecated in
> 2.10, not any 2.9 release, and was supposed to have  gone away in 2.12,
> not in 2.11, as the currently 2.9 deprecation  warnings for zLOG state.
> And why the should the core emit a  deprecation warning?  If the core
> uses it, it by definition shouldn't  (*can't*) be deprecated.   What's
> the goal here?  Removing zLOG is  (at least by any sane measure) totally
> gratuitous in the first place,  we have conflicting reports about which
> version it's going to be  deprecated in, and it's not even actually
> deprecated!  This is the  definition of a clusterfuck.

Some comments in the zLOG module stated that it was intended to deprecate
zLOG in Zope 2.8 afaik (not checking the sources right now). So I 
deprecated it in Zope 2.9 (without migrating all occurrences (mea 
culpa)...a cosmetic problem in my opinion) and it is now removed for Zope 
2.11..


>
> Yes, I know.  I should have spoken up earlier about zLOG.  But to be
> honest I'm just barely keeping my head above water as it is, so I'm
> hoping to be able to trust that people make wise decisions about this
> sort of thing, and my main defense mechanism at this point is limited  to
> covering my eyes and hoping everything will turn out ok.   I'm  hoping
> that people won't removing some random API for the sake of a  hard-on
> over a Platonic ideal.  Is that unreasonable?

At least on the module level we did not remove something without a proper 
replacement.

> So, anyway, I have a really significant number of released products  that
> make use of zLOG.  I can't keep up with the release cycle, or  the
> deprecations.  These products will likely just be broken for new  Zope
> releases and will emit warning messages for stable branches for  some
> period of time.  People are gonna be pissed.  But there's not  much I can
> do about it short of just giving up maintainership of  those products to
> someone who is able and willing to keep up.   There's only like, what,
> maybe 20 people who have demonstrated  willingness to maintain the
> *core*, so it's a pretty fat chance of me  finding one of those people to
> maintain my stuff.

At some point you have to make a cut to get rid of old crap. Fixing the zLOG
issue is a straight forward approach with very little risks for the 
programmer and it won't take too much time..I don't see a major problem 
with that.


>
> There *have* to be other people in the same boat as I am.  Speak up  if
> so!  Zope 2 is really just not the place to make sweeping  innovations.
> We are losing working products as a result of these  "innovations", and
> as a result, probably developers, and as a result  of that, end users.
> In general we are being *way*, *way*, *way* too  aggressive about
> deprecations and API changes in Zope 2.  Sometimes  you just need to live
> with your mistakes.  I'd hope that people will  try to be conservative in
> the future.

I agree almost with everything of that. However being conservative should 
not avoid making progress. This still raises the question: where shall be 
go with Zope 2. My theory is that Zope 3 will be the spare-part factory for 
Zope2 (please no beatings from the Zope 3 world :-)) and that Zope 2 will 
have a long life. This implies that we need to adopt more and more Z3 
technology. Such integration will raise deprecation issue and 
possible...and it is our goal to minimize these issues. ...but that's only 
my personal theory.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20060614/14fe3a35/attachment.bin