qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject [VOTE] Only "export" C++ header files for supported APIs
Date Thu, 27 Jun 2013 05:10:49 GMT
Last week we has a small (number of people) but aomewhat heated
discussion about removing some pieces of deprecated and obsolete QMFv1
code; and removing the qpid::client header files so that no one can use
this API outside the qpid build itself.

There was some grumbling about the QMF removals, but no conclusive
reason not to as far as I could tell.

However Gordon raised a fair point about removing the old client API in
that users may still have code that uses it. Even though it seems that
you would be able to everything with new APIs (either qpid::messaging or
the qmfv2) some people might want some more warning.

My personal objectives with these removals are only really satisfied if
we remove all of this code from what we ship. That's because I want to
only export the headers files for supports APIs: qpid::messaging,
qpid::types and qmf(v2). In order to remove all the other headers we
need to remove everything I removed in [1]. As this is the case I see no
point in doing some of these removals without the others.

So given the objections I don't propose doing this as quickly as 0.24,
but I do propose doing it very soon after we branch 0.24 in the newly
opened 0.25 trunk. This should give people a fair bit of warning and
allow them to stay with 0.24 until they can move their code to something
newer. It will also allow people to try the new 0.25 without the APIs
for a while so we can fix /add stuff before releasing 0.26.

I suggest we add a release note to the 0.24 release together with a
clear statement on the user list about what is going away to say that
0.24 will be the last release that contains the obsolete qmf bits and
the last release that will export the obsolete qpid::client headers
(although they will still exist internally in the qpid build).

So, the call to vote:
[ ] * 0.24 release note as above
    * Notice to user list as above
    * Apply the change in [1] to the trunk of the tree after 0.25 has
      opened.
[ ] Not a good idea, because we're doing/we know someone who is
    doing ... and they won't be able to do ... any more and this is
    why ...

-- Note that I do think that if there is a major lack in capability
   without these APIs etc. then we should put of this removal until
   we can supply the capability with the supported APIs, but I think we
   would need some concrete work items to block the removal.

Thanks

Andrew

[1] https://reviews.apache.org/r/12006/ 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message