Move protos to their own directory for more consistency between different language bindings #180
Conversation
marcelamelara
force-pushed
the
reorg-protos
branch
2 times, most recently
from
8a6b972 to
4a1e8f3
Compare
marcelamelara
force-pushed
the
reorg-protos
branch
from
4a1e8f3 to
ad9aa65
Compare
|
|
||
| import "google/protobuf/struct.proto"; | ||
|
|
||
| option go_package = "github.com/in-toto/attestation/go/spec/v1.0"; | ||
| option go_package = "github.com/in-toto/attestation/go/v1"; |
There was a problem hiding this comment.
Why drop the .0?
We dropped the .0 from the type string because any new fields are supposed to be backwards compatible unless or else they need to increment the major number. However we may want to make backwards compatible changes to these messages, which would rev the minor version, even though the major version and type string would be unchanged.
So I think it's appropriate to keep .0 here so that we can introduce 1.1 in the future with new fields.
Or maybe, the argument goes, if it really is backwards compatible, then producers of the v1 proto would be unaffected by new fields and could just transparently take the new definition. Is that right?
There was a problem hiding this comment.
if it really is backwards compatible, then producers of the v1 proto would be unaffected by new fields and could just transparently take the new definition. Is that right?
Yes, this is the intent. I do realize now that we probably want to document basic protos rules to facilitate this:
- no field re-ordering within a major version
- no field type changes within a major version
- no required fields
Would this work? Also, is there a way to encode the current proto spec version into the definition?
There was a problem hiding this comment.
Yeah that makes sense. Maybe we can just link to this https://protobuf.dev/programming-guides/proto3/#updating ?
is there a way to encode the current proto spec version into the definition?
What do you mean by proto spec version?
There was a problem hiding this comment.
What do you mean by proto spec version?
The statement spec is currently at version 1.0, so is there a way to encode/validate this version number in the corresponding proto? I suspect the answer is no.
There was a problem hiding this comment.
Oh I see. That's something I had wanted to use cuelang.org and vet for. Theoretically you could create cuelang definitions to validate all the rules in the spec. It would be nice to have them for all predicates. If you're still looking for project ideas for that event you're organizing I meant to add that to the list. :)
…ngs packages Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]> Add versioned subdirectory to vsa predicate proto Signed-off-by: Marcela Melara <[email protected]> Remove minor version from protos directory structure; update go package name Signed-off-by: Marcela Melara <[email protected]> Add disclaimer to documentation about protos stability pre v1.1; add how to Signed-off-by: Marcela Melara <[email protected]> Update directory structure and imports Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Aditya Sirish <[email protected]>
marcelamelara
force-pushed
the
reorg-protos
branch
from
f6c8cdc to
8e42494
Compare
This creates a directory structure for all protos. The main goal is to have a directory structure that mirrors the package name/structure we want the different language bindings to have (per #172 (comment)). This also seems like the most sustainable solution to the issue described here.
Cons: The proto package name is changing from what we tagged in v1.0! This will be a breaking change in case there's anyone who is already using our protos. Need to discuss how to handle this divergence from our tagged v1.0 package name.
Blocking #172