You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several different packages in this repo.
scip CLI
SCIP Go bindings, which include a bunch of "hand-written" functionality in addition to the generated code for dealing with Protobufs. This is consumed as a library by src-cli and by scip CLI.
SCIP bindings for TypeScript, Rust and Haskell. Right now, these are all fully generated.
There is also the original Protobuf schema itself.
Not including reprolang since it is for internal testing.
Based on my understanding of Go modules, modules have version numbers but packages don't have a separate version. Right now, we're using 1 Go module which covers both the CLI package and the SCIP bindings.
Some questions and thoughts:
Should we start off with major version 0? Or do we want to use major version 1 now given that the schema has mostly stabilized?
I propose that the generated bindings should always have synced version numbers, and this should be in sync with the schema. Maybe we should add a variant to ProtocolVersion with a major+minor version number (IDK if a patch number is useful for it). Every time we update the schema and the bindings change, we add a new tag to the repo and have CI publish releases for the different bindings.
I'm not entirely sure if the Go bindings (especially the hand-written parts) should have the same version as the other ones, because we may want to tweak certain parts of the code for src-cli. However, splitting the Go bindings into separate packages (or even modules for versioning) would lead to more cumbersome APIs because Go doesn't have extension methods.
For the CLI, I think we should decouple its version from the protocol version, but include the supported SCIP version ranges in the help or version text somewhere. For example, if there is ever a v2 for the SCIP protocol itself, scip CLI v1.x could support both SCIP v1 and SCIP v2 without breaking changes. But I'm not super convinced about this... maybe it is needless complexity/future-proofing.
The text was updated successfully, but these errors were encountered:
There are several different packages in this repo.
Not including reprolang since it is for internal testing.
Based on my understanding of Go modules, modules have version numbers but packages don't have a separate version. Right now, we're using 1 Go module which covers both the CLI package and the SCIP bindings.
Some questions and thoughts:
ProtocolVersion
with a major+minor version number (IDK if a patch number is useful for it). Every time we update the schema and the bindings change, we add a new tag to the repo and have CI publish releases for the different bindings.The text was updated successfully, but these errors were encountered: