ISP versioning architecture: level of duplication

[nick-gorman]

I think one of the main ISP versioning architecture questions is do you:

1. completely duplicate the templater, just call a different version of the templater for each ISP version
2. duplicate templater sub modules as need, and call different sub module versions depending on the ISP version
3. or do you allow line by line switching for functionality
4. another more flexibly approch might be that switching must always be of ispypsa function calls. To allow for changes to happen at any level but also keep the code relatively clean. For example,

if version == 1.0:
   df = vserion_1_function(df)
elif version == 2.0:
   df = vserion_2_function(df)

5. You could also mix approach (1) with other approaches, so you have a unique create_template function for each version but then much of the code of the sub function might be shared between different version of create_template

[nick-gorman]

I worry that approaches other than (1) or (2) will lead to spaghetti code, only using (1)/(2) will lead to massive code duplication.

[EllieKallmier]

Just logging some initial thoughts:

I was doing some reading about software product line engineering (SPLE) and model variability yesterday and saw some potentially useful approaches to guide thinking around this -> mostly the idea of mapping out the key "points of variation" in the code. This book had some interesting discussion around how to approach these kinds of problems, e.g. different domains (problem/solution, feature/decision models etc).

-> At this point, I think that something like (5) feels like the kind of "best of both worlds" approach? And/or if we can spend some time laying out the "points of variation" that might help get a sense for the scale of the challenge a bit more clearly?

[EllieKallmier]

ISP Versioning

• Who is our user base? Who are we making this for?
  • est. 90% of use will just want the latest
• Do we keep the templater sacred or can it evolve?
• Is our ultimate goal usability or conformance/consistency?
  • Person who’s manually changing tables: usability
  • Person who’s writing scripts for repeatability: consistency
• Prioritising backwards compatibility vs. making the best piece of software possible?
  • Good software! Not needing back compatibility at this stage of the package
• What does it look like for us practically right now?
  • Traces for 2026 are not yet published
  • Keep adding new features - but forward looking (kept behind feature flags)
  • e.g.: version that we’re at currently is “frozen” - no more work on that version - we just work on a new version of the templater
  • and in parallel develop structure for data validation (as each table templater gets updated, add data validation)
• Option for workflow:
  • Create the new “base” first - update everything that we currently have up to 2026 ISP (workbook v7.5)
  • With parallel implementation of structure for data validation
  • And parallel implementation of templater ideology update (keeping new features in mind for structural improvements)
  • Then add new features from this new base
  • We like this option!!