Christian Theune wrote:
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 see how it works out.
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 changing stuff and don't tell people in VERY LARGE
LETTERS about it.
I've been arguing for release notes in an earlier discussion. People
generally were of the opinion that the proposals are enough. This makes
clear that they're not. :)
I'd still advocate a document or set of documents per release that
details what changes have been made and how your code should change, and
not to rely on the proposals on the web in our release documentation. If
the proposal makes for perfect release documentation already, then it
should also be easy for you to include it in the Zope source tree.
So, my proposal for Zope 3.4:
* have a developer_notes file or directory somewhere.
* let this contain the developer-visible changes.
* it should be focused on how to change your code. That's the important
bit. Motivations and such might also be useful to have there, but the
main thing should be: this change from so and so to so and so, so to
make this work, do the following.
Zope3-dev mailing list