How to deal with legacy configurations?

[sky-ruiroque]

We have a system in place that maintains past configurations for mobile apps. The configuration version is always the same as the app version. So if we release app versions:

1.0.0
1.1.0
1.2.0

We also have a corresponding JSON configuration in a repo in 3 different files:

1.0.0/config.json
1.1.0/config.json
1.2.0/config.json

We have a business requirement to update older configuration files for apps that are still installed in our user devices.

So we may need to update a value in all of the 3 version configs. In other words, our generated configs do not die when they are published, they keep changing.

How can I accomplish this with Pkl?

For keeping things simple, let's say I have a single config.pkl and Pkl packages for all configurations. So in git we have all of the:

pkl/config.pkl
pkl/out/config@1.0.0.zip
pkl/out/config@1.1.0.zip
pkl/out/config@1.2.0.zip
configs/1.0.0/config.json
configs/1.1.0/config.json
configs/1.2.0/config.json

Since the config.pkl is always evolving and it is now different from the one in previous versions, how can I make changes to old configs and generate the corresponding JSON files?

Is there a strategy for this that I'm missing?

The only practical solution that I can think to do this in a single repo is also to maintain a copy of the config.pkl in separate folders:

configs/1.0.0/config.pkl
configs/1.1.0/config.pkl
configs/1.2.0/config.pkl

But I think this defeats a little what versioning is suppose to be in Git.

Keep in mind that in real life we have a lot more active versions than these 3. And it is not a single config.pkl, it is a lot more complex.

Any ideas on this would be appreciated.

[holzensp]

Typically, especially across minor version changes, there shouldn't be radical changes to the config schema (although I recognise there will be some that critically influence what you want to generate).

One way to do this is to define the set of supported versions as an enum;

typealias SupportedVersion
  ="1.0.0"
  |"1.1.0"
  |"1.2.0"

You can annotate properties with Since or Until annotations and/or encode specific constraints dependent on the version number. Using pkl:reflect in converters allows you to filter out properties based on annotations.

This is assuming, of course, that we're only talking about schema changes in config.pkl, which seems somewhat unlikely (depends on your app, of course, but I also imagine there are changes to default configuration across versions, even if the template doesn't change). Things can get a bit noisy if every property has a if (version > "1.1.0") newValue else oldValue-style version dependency, so at some point, I would recommend switching to release/1.1 Git branches and doing some git ops.