Mathias Bauer wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
I'd say we need a set of highly proficient and highly respected
architects, whose opinion should, at least, be weighted high.
No, please not!
... same opinion here, please don't let's roll off responsibility!
Every code change can break something, so why should API changes be
treated differently? We should keep it simple. The only difference
should be that arbitrary code changes can be done at any time while API
changes can only be done at certain points in time.
I am all for keeping it simple!
We could say: API changes (including changes of language bindings) can
be made in every major release, and you can change everything you want.
... more or less everything you want, I suppose you wanted to say :-)
Of course (as for every code change) you should do that accountably and
talk to other developers that will be influenced by your changes and you
should try to make your changes in a way that the potential work of
others is minimized.
Yes, agreed. Let's apply common sense - I trust in us.
But please no processes, not gate keeper etc. Let things evolve and
assume that all participants in the development process act reasonably.
A bad API change should be treated as any other code change or patch
that we have nowadays: if you see a problem with it, raise your concerns
and discuss.
This would be good communication habits!
Regards,
Mathias
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
