db0 to Programmer [email protected] • 6 days agoThat shadowy placelemmy.dbzer0.comimagemessage-square40fedilinkarrow-up1976arrow-down10
arrow-up1976arrow-down1imageThat shadowy placelemmy.dbzer0.comdb0 to Programmer [email protected] • 6 days agomessage-square40fedilink
minus-square@[email protected]linkfedilinkEnglish16•5 days 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-square@[email protected]linkfedilinkEnglish14•5 days agoYou’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
minus-square@[email protected]linkfedilink1•5 days 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-square@[email protected]linkfedilinkEnglish2•5 days 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-square@[email protected]linkfedilinkEnglish1•4 days agoPublish v3, then add a translation layer for v2 to v3
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.
You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
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.
Publish v3, then add a translation layer for v2 to v3