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

Chris McDonough chrism at plope.com
Wed Jun 14 06:47:37 EDT 2006


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

Warning: This is gonna be ranty and will almost certainly contain  
foul language. ;-)

I've never actually seen a deprecation warning emitted for zLOG.  And  
I'm about as "in the loop" as anybody could expect someone to be, but  
I've not actually worked on the core for maybe six months.  This is  
because I've been trying to ship a long-term customer project, which  
we've settled on 2.8 for, and I haven't been keeping a close eye on  
the checkins list.  Yes, I know.  I know.  I'm bad.  But all of you  
have been there before, I'm pretty sure, so I hope you can sympathize.

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.

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?

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.

The time-based release cycle just amplifies this across many branches  
and point releases, so nobody really knows which products work with  
what branch/release and under what configuration some feature is  
supposed to emit a deprecation warning without a good deal of  
testing.  The *reason* I'm stuck back on 2.8 and haven't upgraded the  
products I maintain to behave nicely on 2.9+ is because I just can't  
keep the fuck up with these sorts of changes.  It's a self- 
perpetuating cycle because the only sane defensive maneuver for me is  
to stick with 2.8 for existing customer projects.  I say to myself  
that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to  
be the current release once I get a chance to breathe, but honestly,  
this is the *last* thing I'll do; I've got plenty of other coding to do.

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.  For my part, I'll try to be  
more in the loop on that sort of stuff on the maillist and try to  
call bullshit more often and more on-time (mea culpa on that).

- - C


On Jun 14, 2006, at 4:39 AM, Andreas Jung wrote:

>
>
> --On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl  
> <jens at dataflake.org> wrote:
>
>>>
>>>> For me, the fact that Zope 2.9.3 still emits
>>>> deprecation warnings on a fresh install (zLOG...) is a pretty bad
>>>> sign.
>>
>> I think this is a dead horse now. Some things were deprecated without
>> actually converting all instances where the deprecated code was  
>> in  use.
>> It's in your power to do something about it, go ahead.
>>
>
> Right. As a rule we must fix any code in the Zope core that would  
> possibly
> spit out a deprecation warning caused by a deprecation warning. At  
> least for zLOG in Zope 2.9 we (possibly only me) were not totally  
> consequent.
>
> -aj_______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEj+lN8sgUgRRnf6URAn6DAKCLodMqkS2We7qQXmYIcaKbP1V++ACfRbwX
CRvmMGvzEeyHQPWwwBFnwdM=
=7oUS
-----END PGP SIGNATURE-----


More information about the Zope-Dev mailing list