Better Versioning Of Resources

[Michaelpalacce]

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 version we 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.8 everything under: 8.0...8.8 will get that specific Class
    • If you have a version 8.8 and 8.10, then 8.9 will go to 8.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.

Example of this in Typescript:

Client Map:

---

Example factory function:

---

Example Patch Class:

with the super:

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.