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 problem for me too! Each time I revisit Zope3, it has
changed very dramaticly! Old code, I wrote for learning Zope3 didn't
work at all, I have do relearn Zope3 for new!
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.
And I realy don't know, what I would think, if I had Zope3 in use on a
productiv system? Schould I really change all packages each half a
year to reflect changes in Zope3?
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.
Don't get me wronge, Zope3 is realy great, it has many good ideas, a
clean design, IMHO it is the best application server out there. But
it still changes to much to be usefull for smaller companies, or even
people like me, for someone just want to use it for hobby! I would not
consider the API as stable! Two much changes! Shure, they all make
things better, but it isn't stable!
Wow, that's a lot of exclamation marks.
You make it sound like we change every single bit of Zope 3 in every
release. We all know that's not the case. Applications that use Zope 3
components such as Plone 2.5, for example, work both with Zope X3 3.0
packages and Zope 3.2 packages. So again, it can't be that bad.
Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
