Mention protobuf

[jvican]

I see you mention Contraband in the README. I think you should mention Protobuf as the standard solution to evolve bincompat class definitions for procools. Protobuf is more popular than protobuf and has awesome support for scala https://github.com/scalapb/ScalaPB.

[jvican]

/cc @jatcwang

[jatcwang]

@jvican I gave it a quick run but when I add a new field to my protobuf definition, the generated case class's unapply method signature changed thus breaks bin compat.

Do you have an example of a library using this for bin compat reasons? Perhaps I'm missing some configuration

[jvican]

We use it in Zinc, and protobuf does not break bincompat in any case. It is a superior alternative than contraband, see this discussion sbt/zinc#351.

In protobuf you can even change the name of a field in a message, and it's still bincompat because it's index-based.

[jatcwang]

I think I'm missing something here. Class file binary compatibility vs protocol/wire binary compatibility are different things and we are addressing the former in this guide.

Here's my test project: https://github.com/jatcwang/test-scalapb-bincompat

It compiles right now, but if you add a new field to person, the signature of Person.unapply changes, causing compilation error and breaking bin compat. Contraband does not have this problem

[jvican]

Doh, you're right, I forgot that scalapb was breaking bincompat at the class level. I complained about this several months ago in their gitter channel, but they didn't seem interested in addressing it. It's a pity.

Do you think it would be useful at least to add a section to the readme explaining what are the differences between wire bincompat and Scala bincompat, and how people may want the former rather than the latter (especially in servers and web apps)?