Frank Schönheit - Sun Microsystems Germany wrote:
Hi Mathias,
My personal take on API changes (changes I would like to suggest or to
do) is more restrictive anyway, but that's only me. If possible I always
would prefer changes that just need recompilations (what usually als
means that Basic macros don't need any work at all as the use
introspection), maybe very small and easy changes in the client code in
some cases.
Which sounds like a good guideline for me (personally), too.
and /definitely/ too restrictive for all intermediate releases.
If the only interest was to fix APIs: yes. But in the context of the
necessity to keep the API stability on a level that is acceptable for
most API users it is a good starting point. If it turns out to be too
restrictive we also could think about more frequent major releases. :-)
*Now* you finally couldn't resist kidding :)
I still think we should keep an open mind for earlier changes. As you
agree below, old style services can (in some respect) changed even now,
without any effect on clients.
i would suggest to start with 4.0 and us see how it works. We can later
on decide if we want to allow API changes for example for even minor
versions as well. It is also possible to differentiate between the kind
of changes that are allowed on even minor releases and in major releases.
But i would like to come back to the initial subject of this thread and
everything else (that is of course very interesting) should we discuss
in a new one.
So again should we use *API.CHANGE-version-number>:* to start a new
thread to discuss a proposed API change for the specified version number?
Please raise your concerns now ... If nobody disagree until Monday it
will be filed as one convention how we discuss potential API changes.
Thanks
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
