Martijn Faassen wrote:
Just to give some real data on this from someone who actually spent time
updating applications: the churn is there, but it's not like this causes
absolutely massive amounts of work, and the deprecation warnings are
usually pretty helpful.
OK.
What's your experience
On 9/5/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
And therefore, we really need to make an
overview over all API changes from 3.0.0 so you can see what happened
(this in addition to the more detailed whats new in vX pages.
Maybe somebody can start such a page somewhere, and we
Stephan Richter wrote:
That's what we do. In fact, I am not even using releases. As soon as a change
happens in the trunk, I migrate the code base I am working on and schedule
updates for the other code I have.
Normal people don't have time or energy to track the trunk. Nor should
they have
Philipp von Weitershausen wrote:
No, only if you want to upgrade to newer Zope versions. And even then
you have a year, not half a year, to upgrade. This deprecation period
was voted on once and I think it's a good compromise.
I think the deprecation period is fine, it's the amount of
Lennart Regebro wrote:
I agree. And as long as you move from one version to the next, it's
not a problems, since we have BBB-code.
I'm sorry, I don't buy this. BBB code goes away, that means you have to
deal with the churn at some point. It's the churn that's the problem...
Chris
--
Jim Fulton wrote:
I don't think it's a matter of being bad. It's a matter of learning
from experience. We broke a lot of new ground in Zope 3 and often got
things wrong because we hadn't done them before.
Okay, we're 5 years down the line now, I think it's time to start
differentiating
Philipp von Weitershausen wrote:
Because it's clutter.
I call BS on that :-S
And because there should preferrably be only one
way to do things.
Indeed, but why break existing code unnecessarilly?
Theuni was recently very confused about the difference between three
different APIs that do
Chris Withers wrote:
Jim Fulton wrote:
I don't think it's a matter of being bad. It's a matter of learning
from experience. We broke a lot of new ground in Zope 3 and often got
things wrong because we hadn't done them before.
Okay, we're 5 years down the line now, I think it's time to
Chris Withers wrote:
Philipp von Weitershausen wrote:
Because it's clutter.
I call BS on that :-S
And because there should preferrably be only one way to do things.
Indeed, but why break existing code unnecessarilly?
Call it BS or unnecessary. The reason why I think breaking existing
Chris Withers wrote:
Lennart Regebro wrote:
I agree. And as long as you move from one version to the next, it's
not a problems, since we have BBB-code.
I'm sorry, I don't buy this. BBB code goes away, that means you have to
deal with the churn at some point. It's the churn that's the
Hi,
Martijn Faassen wrote:
Chris Withers wrote:
Lennart Regebro wrote:
I agree. And as long as you move from one version to the next, it's
not a problems, since we have BBB-code.
I'm sorry, I don't buy this. BBB code goes away, that means you have
to deal with the churn at some point.
Christian Theune wrote:
What's your experience with updating your Zope 3 projects, Chris?
I'll also jump in here: We had to try twice to upgrading a commercial
project based on Zope 3.2 when using the 3.3 beta1, because so much
stuff was actually broken in the release.
As you suggest
On Wednesday 06 September 2006 11:41, Martijn Faassen wrote:
Just to give some real data on this from someone who actually spent time
updating applications: the churn is there, but it's like this causes
absolutely massive amounts of work, and the deprecation warnings are
usually pretty
On Wednesday 06 September 2006 12:05, Christian Theune wrote:
So I'd probably estimate that the cost of upgrading was about 2-3k EUR
for this one project (including the overhead of learning about the new
changes.)
Not bad, I think. Money wisely spent. Now your developers know the new API
that
Stephan Richter wrote:
On Wednesday 06 September 2006 12:05, Christian Theune wrote:
So I'd probably estimate that the cost of upgrading was about 2-3k EUR
for this one project (including the overhead of learning about the new
changes.)
Not bad, I think. Money wisely spent. Now your
Philipp von Weitershausen wrote:
That is unfortunate example of obviously bad deprecation. Deprecation is
hard and it requires a great deal of thought. But it can be manageable
in many cases.
Still feels like there's too much fo it happening in the Zope 3 world.
I refuse to believe that
Dieter Maurer wrote:
But you probably would not prefer if these straight-forward APIs
were continously changing.
I prefer a slightly suboptimal stable API over one that is
optimized in each version in a non backward compatible way.
EXACTLY!
I do see the gain of moving out general purpose
Philipp von Weitershausen wrote:
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a non-backwards-compatible change, 'cos it
requires me to rethink and recode, if not now then at some point in the
future...
being, just
Chris Withers wrote:
Philipp von Weitershausen wrote:
That is unfortunate example of obviously bad deprecation. Deprecation
is hard and it requires a great deal of thought. But it can be
manageable in many cases.
Still feels like there's too much fo it happening in the Zope 3 world.
I
Chris Withers wrote:
Philipp von Weitershausen wrote:
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a non-backwards-compatible change, 'cos it
requires me to rethink and recode, if not now then at some point in the
Why?
Because they'll go away.
Why?
Because it's clutter. And because there should preferrably be only one
way to do things. If we left all the old ways around indefinitely, we'd
have code that uses two or more ways of doing the same thing all over
the place. It would set bad examples, to
Tuesday, September 5, 2006, 1:27:12 PM, you wrote:
Hello!
I was interessted in Zope3 at the early beginning, at still revisit it
each half a year!
But...
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a
Marcus J. Ertl wrote:
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a non-backwards-compatible change, 'cos it
requires me to rethink and recode, if not now then at some point in the
future...
Me too!
That's a real
On Sep 2, 2006, at 1:03 PM, Tres Seaver wrote:
Insulating non-core developers from this kind of churn is what the
façade module 'zapi' was orignally for.
That isn't my recollection. zapi was introduced as an experiment to
make imports simpler. This was done in the days when we used contxt
On Sep 5, 2006, at 5:21 AM, Chris Withers wrote:
I refuse to believe that all the Zope 3 developers are that bad
that they get it wrong in ways which need deprecating so often ;-)
I don't think it's a matter of being bad. It's a matter of
learning from experience. We broke a lot of new
Tuesday, September 5, 2006, 2:06:09 PM, you wrote:
Hello,
Marcus J. Ertl wrote:
I think you're over-dramatizing. Nearly all of the code in the example
application of my book still works with Zope 3.2, so it can't be that bad.
Hmm, for the simple things, it's still good, right. But much of
Fred Drake wrote:
On 9/5/06, Dieter Maurer [EMAIL PROTECTED] wrote:
When I remember right, then I read an important sentence in the
Python style guide -- something along the lines: This is a guide:
you should follow it but there are occasions when you may not do so with
good reasons.
I don't
On 9/5/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
So, in the end, a new style guide would only apply to new packages or
new APIs, which are mostly outside of the Zope 3 core nowadays anyways.
Yes; this I understand. My point was that there's no reason to change
the Z3 style guide,
Tres Seaver wrote:
I'm OK with having in-tree code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that janitorial deprecation is way too common in the tree today:
people decide they don't like the name a method was given, and
Dieter Maurer wrote:
Tres Seaver wrote at 2006-9-2 13:03 -0400:
...
I'm OK with having in-tree code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that janitorial deprecation is way too common in the tree today:
people decide they
Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
It is my impression that it was Zope
baiju m-2 wrote:
This document is maintained as a wiki page, so anyone can edit it.
http://kpug.zwiki.org/WhatIsNewInZope33
This is great! It's probably exactly what we need.
Martin
--
View this message in context:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not prefer if these straight-forward APIs
were continously changing.
I prefer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not prefer if these straight-forward APIs
were
Tres Seaver wrote at 2006-9-2 13:03 -0400:
...
I'm OK with having in-tree code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that janitorial deprecation is way too common in the tree today:
people decide they don't like the name a
snip
What I'm worried about is that we have to come up with a *MUCH* better
way to tell people What is *the single* way to do this or that? and
Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!.
I'd welcome any constructive suggestions. I, for one, suggested a
What's new
Christian Theune wrote:
But to be honest, I too often get the feeling that something in the
process is wrong and we are failing to acknowledge it or work on it.
I think we make it way to hard for people who want to use Zope 3 as
developers making applications with Zope 3.
Why? Because we keep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Philipp von Weitershausen wrote:
Reading the changelog should be enough.
I partially agree on that. This obviously is one issue if you're living
on the trunk or a pre-release branch. It's not clear when to re-read, so
following the checkins is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
Hi,
this is a rant. I don't want to be destructive or disruptive, but I feel
like I need to turn this up right now.
Let's start with something positive: I love Zope 3. I do. I know it
almost since the beginning and I
One thing that would be good is an overview of all API changes that
have happened and in which version it happened. I guess that would be
quite a bit of work, but a page like that would be very helpful if you
wanna port an old app forward and skip a couple of versions.
Christian Theune wrote:
I partially agree on that. This obviously is one issue if you're living
on the trunk or a pre-release branch. It's not clear when to re-read, so
following the checkins is required here.
Yup. But as you said, that's because you're living on the edge.
That's probably my
42 matches
Mail list logo
