qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: codec changes
Date Wed, 15 Apr 2015 18:29:30 GMT
On Wed, 2015-04-15 at 07:13 -0400, Rafael Schloming wrote:
> On Tue, Apr 14, 2015 at 1:27 PM, Alan Conway <aconway@redhat.com> wrote:
> > That works for me, now how do we manage the transition? I don't think we
> > can afford to inflict "yum update proton; all proton apps crash" on our
> > users. That means we cannot change the behavior of existing function
> > names. I don't much like adding encode_foo2 for every encode_foo but I
> > don't see what else to do.
> >
> We could mark the old ones as deprecated and add the new ones as
> pn_xxx_encode2 and provide a feature macro that #defines pn_xxx_encode to
> pn_xxx_encode2. Then after a sufficient transition period we can get rid of
> the old versions.

Along these lines it is also possible to keep ABI (binary library
compatibility) by using versioned library symbols as well. There is a
level of linker magic needed, but at least on Unix it's well understood,
if a little arcane.

Another perfectly reasonable approach would be to create a new name for
the new API and deprecate the old name.

So for example deprecate pn_data_t in favour of pn_value_t (or whatever
better but new name). Where pn_value_t has all the old functionality of
pn_data_t and indeed may be the same internal structure initially, but
with a different interface.

Incidentally C++ does make this easier because it allows function


View raw message