Proposal: Add versioning to builders

[gavento]

Idea: We can have a version=1 parameter for @builder and Builder. The version is just a number that is manually incremented on every change, independently for every builder. (Any comparable could be used but I would stick to numbers).

When the number is incremented and a the builder is added to a runtime, all entries with previous versions of the builder are pruned from the DB along with their children (probably automatically).
On one hand, this risks losing some data on reckless version bump, but is safer for data consistency.

Alternatively, old entries can be just ignored, but their children would need to be somehow ignored too, which seems too complex (unless you have an excellent idea ;) )

@spirali What do you think?

[gavento]

Additionally, versions could be used in upgrade_builder to filter what gets updated - you could provide "migration functions" that stay in the codebase for longer and (semi)automatically get run on runtime creation (or with one function).

Example:

@builder(version=2)
def foo(a, b=1): pass

@foo.migration(from=1, to=2)
def update(config, data):
    config['b'] = 1
    return config, data

(I am happy to implement it!)

[spirali]

I like the idea about versioning builders. I agree that numbers are enough (I think that positive integers more than enough. However there are some potentials for semver).

Automatic delete when versions are changed seems too risky. I would rather see something like an error in initialization and user have 3 options (implement migration function, silent migration, pruning) where last two would be accessible via CLI.

Another option is left entries in the DB and they can be retrieved or shown by browser but using them as dependencies fails.