Mathias Bauer wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
Sorry, I stay with this: API should be as good as reasonably possible
*before* put into the MWS, or even a release. And this requires
discussion, most of the time.
No objection. I just don't want to have any formal process. Announcing a
change, taking part in discussions and reacting on reasonable requests
should be enough.
late but hopefully not too late ;-)
I tend to agree to most of the points and let me summarize the points
that are important for me
- changes of published APIs or changes in language binding are allowed
to major releases only
- keep it simple, no complicate processes
- discussion about API changes are a must
- one requirement -> migration guides. That means i would like to see a
small migration guide for all API changes. A special section in the API
area of the wiki where changes are documented and where API users can
easy see the old and new way to use the API. Especially external
developers, extension developers can look here to adapt there code easy.
This special migration section should be separated by releases.
It should be still naturally that all new APIs or changed APIs are
documented in the DevGuide wiki ;-)
The DevGuide with related examples for beginners adn as consistent
developer docu, the migration page for experienced developers to help
them with changes.
I really don't want to let our API users alone with potential changes.
And for that reason a migration guide is absolutely necessary. Trivial
changes should be only listed, more complex changed should be documented
in detail. Nobody will find it later in the mailing list archives.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
