Join GitHub today
V2 of the configuration file #4355
I have re-reviewed this, about the duplicate logic:
So, I'm not sure if reusing some methods are going to save a lot of code. We have different cases to manage in each version.
In the last commits I change the code to respect the defaults from the schema rather than the db, remove some unused keys from v1 that have a replacement in v2, and added a feature flag to deactivate the v2 on production.
Looking close. I think there are some changes needed still on the feature flag concept, and I think we probably want a
type field, even if it is determined from the use of
I think this PR is ready for a final review, next step is matching the properties between v1 and v2 (where it makes sense of course). And modify the build process to make use of the new properties, and I think we can implement the new features like submodules here too.
I'll be building some projects to make sure this doesn't break the v1, but it shouldn't, I didn't touch the v1 logic here.
I think for consistency the html sphinx keys/value needs to change, but this looks good otherwise. I'm not sure we need to update the design doc, as i think we'll use the schema as a source for generating documentation on the schema, but we could update that if you think it's important. I'm not certain it is though.
Yeah, I think the same, the design doc was to put an initial path in the project. Having the schema is enough I think. What I was wondering is that we'll need to repeat the schema in the docs, but there aren't many keys anyway.