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

[Tres Seaver]

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

Lennart Regebro wrote:
> On 6/14/06, Chris McDonough <chrism at plope.com> wrote:
>> 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.
> 
> Well, ignoring the confusion about zLOG, updating things for a new
> version of Zope with deprecation warnings is not much work. Honestly.
> You update to the new version, look at the depracation warnings, and
> do search/replace until they go away.
> 
> Unless their are compatibility bugs, and that will happen sometimes,
> that's it.
> 
> I don't remember exactly how long it took to go to 2.9 for CPS, but it
> wasn't very much work, and it was all related to changes in Five,
> which you don't seem to use or worry about.

Bzzt.  Five is a *major* culprit for us (Chris and I are often working
together).  The "lookup order" BBB foul in 2.9.2 is one of the major
reasons for sticking to 2.8.

> 2.10 seems to have been
> even less, excepting two bugs in the 2.10 beta. And we do this move
> for CPS during the beta phase, which one typically  shouldn't do.
> Normally you should get rid of the 2.9 deprecation warnings when you
> no longer want to support 2.8. Whi typically would be right about
> after 2.10 is released and 2.8 no longer is officially maintained. If
> you get rid of all deprecation warnings for 2.10 now, your software
> may very well stop working on 2.9. ;)
> 
> Admittedly, now when I think about it, this assumes you have tests for
> the products that have reasonable coverage. If you don't it's much
> worse, because you have to test the whole product manually to get rid
> of all warnings. When you have tests, you are 99% sure things are fine
> once the warnings are gone.

Unit test coverate for custom products is actually quite good.  The
problems are nearly always to do with "third party" products, many of
which have been in "useful stable" mode since long before either
deprectaions or ubiquitous unit testing were part of our community's
development culture.

>> There *have* to be other people in the same boat as I am.
> 
> Yeah, I was in the same boat with EasyPublisher, when Zope moved from
> python 1.5.2 to python 2.something. EasyPublisher stopped working. We
> felt stressed, and did not switch Zope version for a while, staying
> on, I think, 2.3, while everybody else went to 2.5. Remember, there
> was no real deprecation period then, each major version would simply
> have a set of incompatibilities. The result was that the longer we
> waited we had more and more Zope 2.3 bugs to work around, and while
> 3rd party products increased in version we had to use old versions
> because we were on an old zope version. So the longer we waited, the
> greater became not only the upgrade work, but the work of
> circumventing bugs and misfeatures in the old software.
> 
> When I finally DID switch, it still was only a couple of days work,
> and it solved several of our problems. The changes was done for a
> reason, mostly. We *should* have kept up to date continously. It would
> have been less work for us.
> 
>> Zope 2 is really just not the place to make sweeping
>> innovations.
> 
> You are welcome to stay on 2.8 forever if you want. Or 2.7 for that
> matter, it doesn't include Five and so has a much smaller tgz. ;)
> 
> I think alot has been done wrong when it comes to how the innovation
> known as Zope3 has been handled. But I don't think making those
> innovations available to Zope2 is a mistake. I also don't think it's a
> mistake to get rid of the amazing code-duplication that Zope2 and
> Zope3 together holds. Almost the only component that is not duplicated
> is the ZODB. Why should we have two publishers to maintain? And two
> webservers with two WebDav implementations and two of everything else?
> 
> The majority has agreed that the path forward for Zope is to make it
> possible for people to use Zope3 technologies without having to
> rewrite everything from scratch. The changes you see in Zope2 are a
> direct effect of that. You should only get upgrade problems if you
> skip several versions. Other than that, it should pretty much just
> work.

Deprecating something in Zope2 has to be a net win, where the real costs
are part of the calculation.  What we have been arguing about here is
how to evaluate the costs (e.g., breaking otherwise working installed
products) vs. the benefits (e.g., improving "code cleanliness").  This
issue gets particularly sharp when the people evaluating the tradeoff
don't pay the costs themselves (in this example, they don't depend on
the products which break).


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkDEi+gerLs4ltQ4RAsM2AKCTA6fxkC8A9gYIFbvF/2yY+V91cwCfblYg
UpQJSPOcSmdCuOR/DxhmUE8=
=78aq
-----END PGP SIGNATURE-----