protobuff 2.4.1 to 2.6.1

[ChengzhiZhao]

We are using a very old version of protobuff 2.4.1, a new project requires us to use at least 2.6.1. I want to do some tests on my own to make sure serialize/deserialize works. But want to reach out to see if anyone has done this before. What's the best way to test upgrade and any major changes I should be aware of. Appreciate your help!

[marcstreeter]

I have the same question (maybe?) for the python package protobuf==3.1 to python package protobuf=3.6 (on the python side of generated code). We have different projects that are pointing to different python protobuf package versions that need to interact (I/O wise). Does the compiler version need to match the library version? Do library versions need to match exactly between projects? Or is it just 3.x works with whatever 3.y ? If you could just point me to the relevant documentation I'd much appreciate it.

[ChengzhiZhao]

To add some detail: I am using java. We try to use KPL which requires 2.6.1. https://github.com/awslabs/amazon-kinesis-producer/blob/master/java/amazon-kinesis-producer/pom.xml#L77
The current system we have is using 2.4.1.
@marcstreeter, not sure if this is related, but for our case, the KPL library checks the version of protobuff, so excluding 2.6.1 and use 2.4.1 won't do the trick.

[anandolee]

After 3.0.0 we have compatibility, we guarantee:
generated code can always work with runtime that have never version. For example 3.1.0 protoc can work with 3.4.0 runtime. But we do not guarantee old runtime with new protoc.

For 2.4.1 and 2.6.1, I am not sure what major changes you should be aware of. But as our wire format never change, serialize and deserialize should work

We do not change our wire format, so the serialization / deserialization should stay the same. As much as possible, we also try to avoid introducing breaking API changes or behavior changes. That said, there have been bug fixes, enhancement, and subtle changes over the years that could potentially affect your project. I do recommend matching the protoc version with the runtime version though to get the best performance.

There are a couple of things that can help ensure that the upgrade is safe:

1. Testing - if you have good test coverage and the tests continue to pass after upgrade, then it is a good sign. It is hard to say that you are 100% safe yet, but at least it is not breaking in any severe way.
2. Gradual rollout - this is easier to do if your project is a server that receive good traffics. You can try to do a gradual rollout (e.g., 10% with the upgraded version) and monitor the traffics to make sure everything is good.

I think these are general strategies that you can apply to any library upgrade.