Good question. In addition to what Jake wrote, in my opinion it depends mainly on two factors.
First, how quickly are language updates adopted in the field? Some language ecosystems make it easy to migrate, these communities typically do update quickly so one can assume new versions are wide spread very quickly. In that case backwards compatibility is either not that important or very easy to achieve anyway. Others don't, so backward compatibility becomes an absolute need. The second point is the nature of those changes. Are the easy to assimilate into the existing code base? Or ist it a such a groundbreaking change that it basically requires to rewrite the whole stuff? Sure, these are extremes and the truth is often somewhere in between. But you get my point. For example, when upgrading the Haxe libs (which is also a relatively new language) I basically had to change only some stuff around the Int64 support. With Delphi, there are not that much compatibility problems at all. In contrast, the latest big rewrite of the Go bindings was not so long ago. Have fun, JensG ________________________________ Von: Gulshan Singh Gesendet: 09.06.2015 00:09 An: dev@thrift.apache.org Betreff: Stability guarantees for language API Hi, I'm working on Rust bindings for Thrift. I was wondering what the policy is for breaking changes to library APIs, especially for new languages. Can we have our changes merged but specify that the API is unstable for a certain amount of time so people can use it and give feedback, or is everything final after the language is added?
