On Wed, 2015-04-15 at 07:13 -0400, Rafael Schloming wrote: > On Tue, Apr 14, 2015 at 1:27 PM, Alan Conway <[email protected]> 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
