We seem to have reached consensus here, but I haven't seen any commits on
this. We should probably fix this before 0.10 so we don't end up putting
out a new API and then deprecating it in the next release. Is anyone
actually working on this?


On Wed, Apr 15, 2015 at 2:29 PM, Andrew Stitcher <astitc...@redhat.com>

> On Wed, 2015-04-15 at 07:13 -0400, Rafael Schloming wrote:
> > On Tue, Apr 14, 2015 at 1:27 PM, Alan Conway <acon...@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
> overloading.
> Andrew

Reply via email to