Project upgrade path
Problem to solve
(Summarize the problem we are trying to solve in the form of we need to do [A], so that [B] can [C])
As users will start to create Meltano projects, we need to make sure we are not breaking them whenever we want to improve the product.
For instance, if we need to change the format of the
meltano.yml file, most project would then fail to parse the new format and thus crash/undefined behavior.
(For whom are we doing this? Include a persona)
All users of Meltano.
(Include use cases, benefits, and/or goals)
This is a technical necessity, because breaking changes will happen and we should not prevent ourselves from improving the product in fear of breaking something.
(How are we going to solve the problem? Try to include the user journey)
I propose we add a killswitch in Meltano to look at the current project version. If the version is not compatible, we ought to provide a migration path, either automated or documented.
(Ensure the feature doesn't cause any regressions)
- Write adequate test cases and submit test results
- Test results should be reviewed by a person from the team
Links / references
Please note that this was taken from GitLab, to be changed accordingly
Related to #232