From dc8508d55948751fffc28f5b2a2b33b74b4f7377 Mon Sep 17 00:00:00 2001 From: Claus Stadler Date: Fri, 16 Feb 2024 11:45:30 +0100 Subject: [PATCH] removed duplicated file --- docs/version-design.md | 30 ------------------------------ 1 file changed, 30 deletions(-) delete mode 100644 docs/version-design.md diff --git a/docs/version-design.md b/docs/version-design.md deleted file mode 100644 index 1464234..0000000 --- a/docs/version-design.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Version Design -layout: default -parent: Concepts -nav_order: 30 ---- - -## Version Design Considerations - -* Semantic Versioning: A semantic version string is made up from 3 integers in the format `major.minor.incremental`. - -An increment in only the ... - * ... `incremental` component signifies a non-breaking bug fix. - * ... `minor` component signifies a non-breaking feature addition. - * ... `major` component signifies a breaking change. - -Translating these to datasets would roughly mean: - -* An incremental update would be fixing labels -* A minor update would be the addition of new instances and properties -* A major update would be schema changes or the removal of instances or properties (as those instances may have been referenced in the downstream process) - -* It may be tempting to use the format `yyyy.MM.dd` such as `2024.02.15`, however this may make it difficult to publish updated versions of data at that time later on. For example, -if it turns out there was a bug in the data generator and several versions are broken. - - -Possible mitigations: -* Make the data generator revision part of the groupId such as `org.myorg.myproject.datagen.v2` -* Reserve the major version field for revisions `1.20240215.0` -