-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warn if code and schema are of different versions #41
Comments
Many components already provide a version number such as: "/software/components/pam/version" = '${no-snapshot-version}'; Which might help in the implementation of this. |
Please make this optional since our package upgrade schedules are not synchronised to our template releases. |
@ned21 can you clarify a bit more? are you running schemas that are out of sync with components? who puts the schema in place (maunal or scripted?). and how do you expect the component to do the right thing? decoupling schema and component is not for the faint of heart, we had our share of self inflicted issues and that's the main reason i'd like to have this. regardless, ofcourse this will be an opt-in possibility to prevent you from doing wrong things. i see this in a first phase only logging warning or error, not anything more than that. |
Running schemas that are backwards and forwards compatible with different code releases is quite common in the database world - it's how people do A/B testing, etc. We just take care to only deploy breaking schema changes when we know a code change has propagated to our plant. We're managing ok so far but it does take us ages to upgrade and we are currently doing it component by component since we were moving from the pre-unit test versions versions to the maven built code base. |
Indeed! But it makes sense to have a reporting mechanism for the versions (and when they differ) which is what this is about. |
use mkpath instead of make_path to allow EL5 unittests
Modules using data from the configuration tree should issue a warning if the version of their Perl module is different from the schema version used to validate their tree, this can occur if sites do not pin their package versions or build modified packages.
This is a high level tracker to track the implementation of this across repositories as required.
The text was updated successfully, but these errors were encountered: