db0@lemmy.dbzer0.com to Programmer Humor@programming.dev · 12 hours agoThat shadowy placelemmy.dbzer0.comexternal-linkmessage-square30fedilinkarrow-up1733arrow-down10
arrow-up1733arrow-down1external-linkThat shadowy placelemmy.dbzer0.comdb0@lemmy.dbzer0.com to Programmer Humor@programming.dev · 12 hours agomessage-square30fedilink
minus-squareCosmicTurtle0@lemmy.dbzer0.comlinkfedilinkEnglisharrow-up8·7 hours agoIf you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
minus-squareLongpork3@lemmy.nzlinkfedilinkarrow-up2·4 hours agoA translation layer could be used, no? Check api version, translate any v1 specific calls into their v2 counterparts, then submit the v2 request?
minus-squareCosmicTurtle0@lemmy.dbzer0.comlinkfedilinkEnglisharrow-up1·2 hours agoThis isn’t really efficient because when v2 gets updated now you have to update the translation layer as well. Any improvements you made in v2 would likely not translate. Essentially the best way is to provide users with an incentive to switch. Perhaps a new feature or more requests.
minus-squarebleistift2@sopuli.xyzlinkfedilinkEnglisharrow-up6·7 hours agoYou’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
If you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
A translation layer could be used, no? Check api version, translate any v1 specific calls into their v2 counterparts, then submit the v2 request?
This isn’t really efficient because when v2 gets updated now you have to update the translation layer as well.
Any improvements you made in v2 would likely not translate.
Essentially the best way is to provide users with an incentive to switch. Perhaps a new feature or more requests.
You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.