michaelweghorn added a comment.
In D18179#391664 <https://phabricator.kde.org/D18179#391664>, @aacid wrote: > Maybe an enum is better than a bool so if in the future more scaling options are implemented we don't need to change the signature again? Sounds reasonable. I'll change that in the next version. INLINE COMMENTS > aacid wrote in fileprinter.h:82 > this is not binary compatible, we try not to break the binary compatibility > of the okular public classes. > > Add another method (without the default values) and make this one call the > new one. > > Same for all the functions you're adding new parameters to. > > Or you can try to convince me that maintainting binary compatibilty is not > needed :D I don't really feel up to the task of convincing you. :D The only point I can come up with is that your comment in ab96e0c07def2f572a8bb3e32f90e597e6761627 <https://phabricator.kde.org/R223:ab96e0c07def2f572a8bb3e32f90e597e6761627> indicates that that commit //might// have broken binary compatibility already and thus it might be worth considering bumping the so version anyway (in which case I think this here should no longer be any problem, but I haven't really had to deal with binary compatibility in the past). Otherwise, I don't mind adding the suggested extra methods. Will those extra methods then stay there forever or can the methods then be "merged" again once another ABI-incompatible change is done? Just out of curiosity: Do you know of specific applications/third-party generators,... that use libokularcore? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18179 To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, ngraham, darcyshen
