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

Reply via email to