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?
--Rafael On Wed, Apr 15, 2015 at 2:29 PM, Andrew Stitcher <astitc...@redhat.com> wrote: > 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 > > >
