Handling releases after sdk upgrade

I’m seeing users that take over a month to update their binary, which makes sdk upgrades difficult. Since publishes to newer sdks are ignored by older sdk clients, bug fixes and new feature releases become a major headache. I’ve considered branching master every time the sdk updates and just cherry picking any critical bug fixes to the older branch when necessary.

Would publish to the same release channel with an older sdk overwrite the previous publication to the new sdk? That is, if I publish revision 10 with sdk 26 and then publish revision 11 with sdk 24, would a binary using sdk 26 see revision 10 or 11?

Has anyone else had to deal with code pushes to out of date binaries?

hi @alxyuu1,

Standalone binaries will always get the most recent compatible publication, they also support all the available SDK versions at the time of build. For example, if you built a standalone binary last month, it will support SDK versions 18 - 25. A standalone binary built today will support SDK versions 19-26.

It’s usually simpler if you have a different release channel for each standalone binary, because you can publish your bug fixes to the appropriate channels and know that they will only be picked up by ONE standalone binary.

If both your standalone binaries are pulling from the same release channel, you can do the following:

  1. publish SDK 25 with bug fixes (call this Publication A)
  2. publish SDK 26 with bug fixes (call this Publication B)

Let the earlier binary that supports SDK18-25 be called Binary A, and the later binary that supports SDK 19-26 be called Binary B. Binary A will get Publication A, because it is the most recent compatible publication, as it doesnt support SDK 26. Binary B will get Publication B, because while it does support Publication A, Publication B is the most recently published one.

More info here:


This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.