db0 to Programmer [email protected] • 3 months agoThat shadowy placelemmy.dbzer0.comimagemessage-square40fedilinkarrow-up11.03K
arrow-up11.03KimageThat shadowy placelemmy.dbzer0.comdb0 to Programmer [email protected] • 3 months agomessage-square40fedilink
minus-square@[email protected]linkfedilinkEnglish17•3 months 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]linkfedilinkEnglish15•3 months agoYou’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
minus-square@[email protected]linkfedilink2•3 months 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•3 months 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•3 months 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