Open
Description
Description
Changes to the APIs in different solutions lead to a lot of checks of which minor/patch version we are using of a specific API and then doing some complex conditionals inline at random places to trigger different logic. This should be improved.
**NOTE: This Issue is NOT related to major version changes, rather only for minor and patch versions! How major changes are handled is a part of #305
Proposed change
- We need to separate parts of the business logic of specific stores away from the stores themselves and move it to a separate class
- This class will be created by a Factory, given the
versionwe want - Versioning will work by:
- Add a map with versions pointing to Classess for that version
- Have a default option for things that are unmatched
- Versions will match up to a version, aka if you have version
8.8everything under:8.0...8.8will get that specific Class - If you have a version
8.8and8.10, then8.9will go to8.10 - Each versioned class will essentially be a patch from the default one
- The versioned classes returned by the factory will implement the strategy pattern and the stores will use the correct strategy based on what was returned by the factory.
- This class will be created by a Factory, given the
Example of this in Typescript:
Client Map:
Example factory function:
Example Patch Class:
with the super:
