Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should we version the various packages? #24

Open
varungandhi-src opened this issue May 24, 2022 · 1 comment
Open

How should we version the various packages? #24

varungandhi-src opened this issue May 24, 2022 · 1 comment

Comments

@varungandhi-src
Copy link
Contributor

varungandhi-src commented May 24, 2022

There are several different packages in this repo.

  1. scip CLI
  2. 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.
  3. SCIP bindings for TypeScript, Rust and Haskell. Right now, these are all fully generated.
  4. 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:

  1. 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?
  2. 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.
  3. 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.
  4. 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.
@olafurpg
Copy link
Member

olafurpg commented Jun 2, 2022

  1. I think it's OK to start with version v0.x but aim to cut a v1 in the not-so-distant future
  2. The simplest solution is probably to make the protocol version a message like this
message SemanticVersion {
  int32 major = 1;
  int32 minor = 2;
  int32 patch = 3;
  string suffix = 4;
}
  1. Let's version the Go bindings together with the rest of the spec. A bugfix in the conversion tool will be a patch bump.
  2. I'd version the cli together with the rest of the schema. This is the simplest solution for now, both for us as maintainers and for downstream users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants