feat!: add support for mulitple version of cdevents' specifications #19
Conversation
davidB
changed the title
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
… spec Signed-off-by: David Bernard <david.bernard.31@gmail.com>
- link as git submodule several versions of cdevents specs - add version into module name of subject's content - generate a module per specs with alias to the versionned subejct's content module - generate a module `latest` with alias to the latest version of each subject's content module - ignore subject'content with modifier in their version - update tests to load every json schema and test it (selection based on `context.type` FIX #16 Signed-off-by: David Bernard <david.bernard.31@gmail.com>
Signed-off-by: David Bernard <david.bernard.31@gmail.com>
davidB
force-pushed
the
feat_multi_version_support
branch
from
1549ef7 to
f3f353b
Compare
Signed-off-by: David Bernard <david.bernard.31@gmail.com>
davidB
force-pushed
the
feat_multi_version_support
branch
from
7aa5b5b to
9b1d7a3
Compare
Signed-off-by: David Bernard <david.bernard.31@gmail.com>
davidB
force-pushed
the
feat_multi_version_support
branch
from
9b1d7a3 to
d38118f
Compare
| [submodule "cdevents-specs/spec-v0.3"] | ||
| path = cdevents-specs/spec-v0.3 | ||
| url = https://github.com/cdevents/spec.git | ||
| branch = spec-v0.3 | ||
| [submodule "cdevents-specs/main"] | ||
| path = cdevents-specs/main | ||
| url = https://github.com/cdevents/spec.git |
There was a problem hiding this comment.
I like the idea of having multiple submodules, we might do the same for other SDKs.
I'm not entirely sure about the main one - I think it's fine as long as there is a way to exclude it from a release. Events on main in the spec have a -draft version and are not meant to be used until they are released, so we should not release an SDK that supports producing them.
There was a problem hiding this comment.
the generator exclude every json with "draft" or any modifier in the version fragment from context.type.
|
|
||
| use serde::{Serialize, Deserialize}; | ||
| pub mod latest { |
There was a problem hiding this comment.
While it's nice to generate latest for dev preview sake, we should not include it in a release
There was a problem hiding this comment.
the purpose of latest is not for dev preview, it's to ease the development of library.
scenario for "latest":
- inside the code, the developer (user of the SDK) uses the "latest" module
- when the version of the SDK is upgraded, the compiler will raise an error for incompatible event structure, then the developer can
- update the code to match the new structure
- OR change "latest" to a specific "spec module"
- OR change from the "latest" module to the parent and use the per version event.
By using "latest" module, developers can easily upgrade to the latest version of each event, maybe by changing the SDK's version number. (The "latest" module behaves similarly to the behavior in other SDKs or currently on the main branch.)
For developer that don't use the "latest" module, then upgrading means changing the dependencies and do not forgot to change each event version (via per spec module, or each one) inside the code. So maybe a wrong feeling of upgrade.
The "latest" scenario is also the one most compatible with tool like dependabot, renovate,...
| use serde::{Serialize, Deserialize}; | ||
| pub mod latest { | ||
| pub use super::artifact_packaged_0_1_1 as artifact_packaged; | ||
| pub use super::artifact_published_0_1_1 as artifact_published; |
There was a problem hiding this comment.
It may be worth checking the generator logic - on main the artifact published event is on version 0.2.0-draft (https://github.com/cdevents/spec/blob/main/schemas/artifactpublished.json)
There was a problem hiding this comment.
As I mention "-draft" are not generated (too unstable, and also confusing in term of naming modules,...)
The issue with "main" is that we need to update the git submodule to have the latest version. |
latestwith alias to the latest version of each subject's content modulecontext.typeFIX #16