Specification versioning system

[ghost]

Would be useful for implementations to state what version of the protodef spec they support. Discussing possibilities in ProtoDef Gitter

[rom1504]

I think version tags are enough to solve this problem. (as is done with https://github.com/PrismarineJS/minecraft-data/releases and its wrappers https://github.com/PrismarineJS/node-minecraft-data/commits/master )

[ghost]

Yup. Sounds good.

[roblabla]

I'm a bit iffy about versioning the protodef spec itself. A protodef file is supposed to say "I need an implementation of X, Y and Z" (by setting them to native), even stuff in the core protodef.

I say "is supposed to", I don't think there's anything forcing people right now, but maybe we should.

The idea is that each subcomponent (varint, count, struct, etc...) shouldn't ever break backward compatibility. I know this is a strong statement to make, but I think it's pretty important.

For external datatypes, life's a bit more complicated. What if an external datatype wants to change how its typeargs work ? IMO, a best effort should be made not to break backward compat, but sometimes there's no choice ?

[ghost]

Yes, the version number would indicate breaking changes.

[ghost]

Just like protobuf, the major number changes becuase the syntax changes, but there is a compatibility mode option

[roblabla]

here's the thing: the format itself does not exist right now. The only thing standardized is a list of datatypes. And those are not subject to change.

We probably should standardize a bit more at one point, but for now everything's a blur. I'm still not sure where I want to draw the line at what's standardized (Should we standardize the JSON format ? Is the NMP format okay ? What about multi-states ? Should a protodef file be a single state or should it potentially contain multiple ones ?)

My goal for protodef to be meaningful would be that it should be enough to feed a protodef description (with a bit of code to handle potential state changes) to a software to make it spit a Wireshark Dissector.

---

I went off-topic here. The point being, what the standard contains right now is not a file format. It's just a bunch of datatypes. Versioning them would bring no advantages. What's the use-case for versioning ?

[ghost]

The use-case of versioning is for when we add more datatypes, to indicate if an older version of ProtoDef is compatible, like v1 (an example) didn't contain little-endian but v2 did, the user should know which one they're running so that they can know when they need v2 for those extra datatypes. Let me know if you'd like me to make a pull request adding a package.json possible for use as a versioning scheme? It doesn't need to be published to npm but when github tags are used, APIs are able to compare the ProtoDef version to the node-protodef or elixir-protodef version. Let me know what you think.