We use protocol buffers on a game and we use the back compat stuff all the time.

We include a version number with each release of the game. If we change a proto we add new fields and deprecate old ones and increment the version. We use the version number to run a series of steps on each proto to upgrade old fields to new ones.

▲

swiftcoder 7 days ago | parent [-]

> We use the version number to run a series of steps on each proto to upgrade old fields to new ones

It sounds like you've built your own back-compat functionality on top of protobuf?

The only functionality protobuf is giving you here is optional-by-default (and mandatory version numbers, but most wire formats require that)

▲

tyleo 6 days ago | parent [-]

Yeah, I’d probably say something more like, “we leverage protobuf built ins to make a slightly more advanced back compat system”

We do rename deprecated fields and often give new fields their names. We rely on the field number to make that work.

▲

vkou 6 days ago | parent [-]

> We do rename deprecated fields and often give new fields their names. We rely on the field number to make that work.

Why share names? Wouldn't it be safer to, well, not?

	▲	tyleo 3 days ago \| parent [-]
		The code becomes hard to read. You might need to change int health to float health. In that case “health” properly describes the idea. We’d change this to int DEPRECATED_health and float health. Folks can argue that’s ugly but I’ve not seen one instance of someone confused.