Robert Greig wrote:
2008/10/8 Aidan Skinner <[EMAIL PROTECTED]>:
It implies that the API is immature, which it is. The only stable API that
I'm aware of Qpid having is the JMS one. Everything else has a tendancy to
change / be completely rewritten between versions.
This highlights the insanity (in my view) of basing an API on the
protocol. I have already made my position on this clear in the past so
I won't labour the point!
In general, I think people expect API compatibility within major
versions. We would need an API migration plan for non-major releases
too - perhaps some backwards compatibility but with deprecation.
I think that many people view the version number as an indication of
maturity. API compatibility is just *expected* from any professional
organisation that has any understanding of enterprise requirements.
RG
Note sure everything changes between version is correct, more like
changed a lot from first cut of
something until it has been around a while. The API between M3 and M4
C++ are the same, same
goes for Python, JMS is JMS. The new classes that where just added for
HA don't break any of the
existing classes and there is a thin layer in the client to protect
against API thrashing. I think the
exception is WCF added for M4. Yes I know we can do more on the APIs &
as developers we always
want to keep things open to change but...
I expect that we would NOT be altering the API much between releases,
and when we do we provide
compatibility. I know we where not in this mode in M1 timeframe but my
view is that we need to be now.
Or put another way, if someone created a new client for perl, I would
expect the API to change for a
while, but then stabilize. There will always be something in Qpid that
is new. It would be better to
create a table and show users which APIs are considered stable, and not
tar the everything with the
maturity level of new API's which are in minority in the project.
Carl.
