There was similar situation that Git DVCS developers faced when adding new features to its network protocol. The first version was not designed with extendability in mind, but because exchange was done with pkt-lines, with length as part of payload but original parsing stopped at NUL ("\0") character they have shoe-horned information about extensions ('capabilities', this time in extendable space separated list of capabilites format) after NUL character; old clients skip capabilities list, new clients parse it and reply which they want to use.
Backward compatibility was preserved with a very few exception for server-client transfer thorough whole existence of Git.
Posted Sep 26, 2013 11:53 UTC (Thu) by davecb (subscriber, #1574)
[Link]
An elegant approach!
It's a lot easier in modern programming languages, where a new variant can be intruduced by adding a parameter. For common cases, this can hide the ened for versioning and future-proofing from the developer.
Unless, of course, you're making a change from an absolute date to a relative one, both expressed as an integer (:-()