3 ms·

> I told it to install "protobuf" since I use that library in my build tool. That actually installed "protobuf-24.4,1" which is some insane version number I'd

by saghm 3y ago

> I told it to install "protobuf" since I use that library in my build tool. That actually installed "protobuf-24.4,1" which is some insane version number I'd never seen before. All of my other systems are all running 3.x.x type versions. I was curious about this, so I took a look at the list of protobuf releases[0] and they're...confusing, to say the least. Chronologically, the most recent tags at the time I write this comment are: v5.27.0-rc1 v3.27.0-rc1 v27.0-rc1 v27-dev v26.1 v5.26.1 v3.26.1 v26.1 v26.0 v5.26.0 v3.26.0 Does anyone here happen to know what's going on here? As best I can tell, they're simultaneously supporting 3 major versions while keeping their minor and patch versions in lockstep, and then having one major version be implicit? I can almost imagine a scenario where they started out with just major and minor version and then realized they wanted to make breaking changes, which led them down the path of adding a third separate number to the versions, but if they already were going down the path of assuming "wider" versions are newer , why not just stop using version numbers with only major-minor and instead just add a 0 or 1 to the front of all of the continuations of that branch? Also, why synchronize every single minor and patch version between all three major versions? I can understand why it might be useful to continue providing support for multiple major versions at the same time, but I'd expect that _sometimes_ there might be a bug or something in only one of them, and pushing out a release of the other two that don't contain any changes would be pretty strange. [0]: https://github.com/protocolbuffers/protobuf/tags https://github.com/protocolbuffers/protobuf/tags

maeln 3y ago
It's because they changed the versioning format: https://github.com/protocolbuffers/protobuf/releases?page=5 https://github.com/protocolbuffers/protobuf/releases?page=5 / https://protobuf.dev/news/2022-05-06/ https://protobuf.dev/news/2022-05-06/ But I suppose old version still receive bugfixes.
- BobbyTables2 3y ago
  If only they had a language agnostic way of encoding version information… Perhaps someone wrote a library for that…
- saghm 3y ago
  I don't understand how either of those links clarify anything; the former shows that they had a version 3.y.z and a version 20.y, and the later shows a change from 3.20.x to 4.21.x, but none of it gives any explanation for why a new major version should "inherit" the old minor version instead of restarting from 0, or why they kept around `x.y` when updating to use `x.y.z` instead of just continuing the existing branch as `0.x+1.y` or `1.x+1.y`. If anything, the fact that they already seem to assume that new major versions should always inherit the minor version would make it _more_ consistent than having one "special" branch that has "narrower" versions.
ori_b 3y ago
I think protobuf might just be a performance art piece, exploring the question of how much complexity it's possible to insert into a simple concept.
- BobbyTables2 3y ago
  Indeed. Having used it and examined the resulting binary formats it uses, I don’t get it. Google makes some nice things, but protobuf isn’t one of them. IIRC (5 yes ago), it was somewhat self describing with respect to struct offsets but had no (data format) versioning or type information. Never understood that design choice, even in mixed endian+architecture environments. Ends up being horribly inefficient for small/one-time instances, and not all that great for client/server use. We were looking at it to get away from C structs and handmade serialization — only to unexpectedly realize that our methods were still better. (We genuinely did not want this outcome!). JSON/yaml were not options for other reasons. Protobuf is the modern realization of “the king has no clothes”.
- bitcharmer 3y ago
  That depends. In low latency environments you will see some protobuf but not as much as you'd think. SBE is quite common with the odd exception of some bespoke serialization protocols with delta compression and such.

by saghm 3y ago

maeln 3y ago

It's because they changed the versioning format: https://github.com/protocolbuffers/protobuf/releases?page=5 https://github.com/protocolbuffers/protobuf/releases?page=5 / https://protobuf.dev/news/2022-05-06/ https://protobuf.dev/news/2022-05-06/ But I suppose old version still receive bugfixes.

BobbyTables2 3y ago
If only they had a language agnostic way of encoding version information… Perhaps someone wrote a library for that…
saghm 3y ago
I don't understand how either of those links clarify anything; the former shows that they had a version 3.y.z and a version 20.y, and the later shows a change from 3.20.x to 4.21.x, but none of it gives any explanation for why a new major version should "inherit" the old minor version instead of restarting from 0, or why they kept around `x.y` when updating to use `x.y.z` instead of just continuing the existing branch as `0.x+1.y` or `1.x+1.y`. If anything, the fact that they already seem to assume that new major versions should always inherit the minor version would make it _more_ consistent than having one "special" branch that has "narrower" versions.

ori_b 3y ago

I think protobuf might just be a performance art piece, exploring the question of how much complexity it's possible to insert into a simple concept.

BobbyTables2 3y ago
Indeed. Having used it and examined the resulting binary formats it uses, I don’t get it. Google makes some nice things, but protobuf isn’t one of them. IIRC (5 yes ago), it was somewhat self describing with respect to struct offsets but had no (data format) versioning or type information. Never understood that design choice, even in mixed endian+architecture environments. Ends up being horribly inefficient for small/one-time instances, and not all that great for client/server use. We were looking at it to get away from C structs and handmade serialization — only to unexpectedly realize that our methods were still better. (We genuinely did not want this outcome!). JSON/yaml were not options for other reasons. Protobuf is the modern realization of “the king has no clothes”.
bitcharmer 3y ago
That depends. In low latency environments you will see some protobuf but not as much as you'd think. SBE is quite common with the odd exception of some bespoke serialization protocols with delta compression and such.