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
Jim Fulton wrote:
Christian Theune wrote:
Why? Because we keep changing stuff and don't tell people in VERY LARGE
LETTERS about it.
Actually, you highlighted the wrong bit, the important bit is:
BECAUSE WE KEEP CHANGING STUFF
This is really the central point (or, at least, IMO, the most
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
On Sep 6, 2006, at 6:41 AM, Chris Withers wrote:
Jim Fulton wrote:
...
Zope 3 was declared ready for production because people were using
it in production,
A mistake perhaps?
I don't think so.
...
People who used Zope 3 should have been made aware of these
issues. Maybe there
I apologize in advance to most of you who are not playing with
zc.buildout.
For those of who are ...
I don't have a dedicated list for zc.buildout yet, but I imagine that
most of you are on thse lists
This morning I made new releases of zc.buildout, zc.recipe.egg and
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
16 matches
Mail list logo
