sourcegraph / scip

SCIP Code Intelligence Protocol
Apache License 2.0
257 stars 32 forks source link

How should we version the various packages? #24

Open varungandhi-src opened 2 years ago

varungandhi-src commented 2 years ago

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 commented 2 years ago
  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.