From 1b8649359979aaa435ede2df8468f3049bb9d42e Mon Sep 17 00:00:00 2001 From: Maxim Kulkin Date: Thu, 19 Sep 2013 16:11:57 +0400 Subject: [PATCH] Minor README reorganizations --- README.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 02277b3..8d4d590 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ Each project consists of multiple executables, each of which can have their cust Config file consists of groups, groups consist of parameters, parameter is key-value pair. -Schema checks: +Schema inspections: * Ensure that all present parameters belong to correct section (group) and have proper values (according to parameter's type). * Ensure that all required parameters are present. * Warn if some parameter is present multiple times. @@ -18,7 +18,11 @@ Schema checks: Config parameters can reference additional files, which can have their own syntax and schema. E.g. logging.conf, api-paste config. Those files require a separate inspections procedures. -Some configuration parameters reference Python classes, so in order to validate that it is required to know versions of all components and have list of all classes in them with information about component versions when this class first appeared and when it disappears. The same applies to schema: each configuration option should have information on versions and when validating schema the most recent config option record should be used for schema validation. +Some configuration parameters reference Python classes, so in order to validate that it is required to know versions of all components and have list of all classes in them with information about component versions when this class first appeared and when it disappears. + +Config schema +------------- +Each configuration option should have information on versions. When validating schema, the most recent config option record should be used for schema validation. Changes in schema can be small between build (maintanence) releases, so there is no need to store whole schema for those. It should be stored in a diff-like format: for each known version there should be records on configuration changes like added/changed option, removed option. To validate configuration for paritcular version a configuration schema snapshot for that version will need to be calculated. Major (and maybe minor) versions can have the whole schema to speed up schema snapshot calculus.