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

[Chris McDonough]

On Wed, 2006-06-14 at 13:34 +0200, Lennart Regebro wrote:
> On 6/14/06, Chris McDonough <chrism at plope.com> wrote:
> 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.

I realize it's easy to forget, because I'm clearly no genius, but I do
write Zope software for a living, so updating to new versions of things
is something I've dealt with in the past.

> 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.

Oh, geez.  I maintain a large Five-using product.  It may be one of the
largest in existence (which is not meant as bragging, it's just probably
true).  It's currently 31,000 lines of Python, most of which is in
browser views, another 12,000 lines of ZPT, and about 3000 lines of SQL.

Therefore, I do have a stake in reasonably-recent Zope releases. There
are others like me who maintain large 3rd-party code bases that actually
depend on this stuff who aren't actively involved in the development of
all of the pieces of the framework.  These sorts of people just can't
afford to upgrade in lockstep with the various current release cycles.
These are the people I'd like to avoid pissing off.

FWIW, I can actually deal with the churn, I'm not going anywhere anytime
soon, but I can imagine not sticking around and ditching Zope for
something more stable if I were less involved.

> 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.

The product I speak of above has 700 individual unit tests and still has
bugs.  Shrug.  I expect some breakage, and the tests will catch most of
them, and that's fine.  But I also have maybe five or six open source
products that I maintain which don't see attention every week or even
every month or sometimes every six months, because I'm working on other
stuff.  These are problematic for me to keep in sync, which causes
problems for other folks.

> 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.

But really, in honest-to-god reality, you probably couldn't have while
simultaneously serving your customers' immediate best interests.  That's
of course a subjective judgment, but at least think it over a little
before saying you could have.

> > 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. ;)

Thanks for giving me your permission to do that.

> 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. 

Me neither.  None of what I'm talking about has yet been related to
Five.  The two things that have brought this up in my mind so far have
been the deprecation of 'methods' in __init__.py and the zLOG
clusterfuck.  Those things have nothing to do with Five or Zope 3.

> 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?

One good reason: because the old one works and hundreds if not
thousands, if not tens of thousands already use it, and there is *no
immediate benefit* for them to switch to something different.

> 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 majority has been pretty sheltered so far, IMO.  I'm still
struggling to explain the concept of *Python scripts* to some of my
customers.

>  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.

So "don't worry about it" is your opinion?  I don't think that's a
reasonable position.  But then again, what do I know, I'm only a dumb
end user I suppose.  And who wants all those pesky end users anyway?

- C