[WIP] - New Versioning #284
Conversation
| @@ -1,6 +1,6 @@ | |||
| CREATE TABLE protocols ( | |||
| id CHARACTER VARYING(255) NOT NULL, | |||
| version INTEGER NOT NULL, | |||
| version VARCHAR(20) NOT NULL CHECK (version ~ '^(\d+\.)?(\d+\.)?(\*|\d+)$'), | |||
There was a problem hiding this comment.
I did this here because of the tests, but I guess the correct way would be to create a migration?
| @@ -3,5 +3,5 @@ CREATE TYPE idl AS ENUM ('avro', 'protobuf', 'mu', 'openapi', 'scala'); | |||
| CREATE TABLE metaprotocols ( | |||
| id CHARACTER VARYING(255) PRIMARY KEY, | |||
| idl_name idl NOT NULL, | |||
| version INTEGER NOT NULL | |||
| version VARCHAR(20) NOT NULL CHECK (version ~ '^(\d+\.)?(\d+\.)?(\*|\d+)$') | |||
| /** An String that matches with format xx.yy.zz, xx.yy, xx */ | ||
| type ProtocolVersionRefined = | ||
| String Refined MatchesRegex[W.`"""^(\\d+\\.)?(\\d+\\.)?(\\*|\\d+)$"""`.T] | ||
| object ProtocolVersionRefined extends RefinedTypeOps[ProtocolVersionRefined, String] { |
There was a problem hiding this comment.
Maybe we don't need this anymore... I have to give it a deeper look
| VALUES ($id, $idl_name::idl, 1) | ||
| ON CONFLICT (id) DO UPDATE SET version = metaprotocols.version + 1 | ||
| VALUES ($id, $idl_name::idl, $protocol_version) | ||
| ON CONFLICT (id) DO UPDATE SET version = ${protocol_version.incRevision} |
There was a problem hiding this comment.
The Revision is updated by default, but this can be changed
|
Thanks @Yawolf ! I believe @BenFradet used this in the past, I'd like to know his thoughts. Also, the other thing is that we may miss compatibility with Schema Registry at API level 🤔 |
|
yes, I think the idea in the post has several flaws especially regarding user interaction: people don't know what version to choose when they change their schema. I think a simpler dichotomy would be:
Regarding the api compatbility with schema registry, we can still do:
so it will still be mostly compatible |
@juanpedromoreno I gave a fast look to this last Friday. Maybe I'm wrong but in schema registry the versions are
|
Does Schema Registry accept versions such as 1.2, or 2.7? If so, then much better, but I thought it does not. |
|
no it doesn't but what I meant is that we can work around compatibility, we already abstract routing for compatibility reasons we can also abstract versioning 🙂 |
I was thinking to create a function to generate new Schema Registry compatible versions from this new versioning. Something like: 1.0.0 -> 100 But this is only an injective relation, given a Schema Registry version that does not exist in our service, the only thing we could do it to set the current version in Shema Registry as the Model Version in out versioning: 1 -> 1.0.0 |
|
I'm fine with the Ben's proposal here
👍 Thanks both! |
New Versioning
We want to offer better versioning in Compendium, more clear and robust than what we have right now. In this PR I present a new way of versioning.
References
I used this post as a guideline.
How is it defined?
This new versioning is quite similar to classic SemVer, but with a few changes. The format is this:
model.revision.additionIn then post they propose this format:
model-revision-additionBut I don't like it and find it less intuitive than the one I used.
The default, or first, version of a schema must be
1.0.0.Show me the bowels!
Although in DB and HTTP Responses the version will appear as a String with the format I exposed above, in the code, a Version is a case class with this shape:
Where
ModelVersion,RevisionVersion, andAdditionVersionare Tagged Types, of typeIntwithEq,Show,Decoder,Encoder, andMonoidinstances.In this way, it is much easier to handle a version or update it. That part of the code is a little bit documented.