Support patching an extension release's metadata

[gastaldi]

/cc @holly-cummins

[holly-cummins]

@gastaldi, do you think it's worth updating the metadata with an extra field to say 'this has been patched' when we do the patch? I'm imagining myself staring at what's coming back from the registry, and then staring at what's in github, and scratching my head trying to figure out why they don't match. I think including a full audit trail of what-changed-and-when in the metadata of the extension would be overkill, but maybe some indicator that this was patched data would be useful.

[gastaldi]

@holly-cummins each entity has a createdAt attribute. We could have an updatedAt field and return both in the metadata when requested. WDYT?

[holly-cummins]

@holly-cummins each entity has a createdAt attribute. We could have an updatedAt field and return both in the metadata when requested. WDYT?

If an extension did a new release, would it change the 'createdAt' or 'updatedAt' field? I really like the idea of using these fields, but we might need three to fully capture the different variations of 'came into existence', 'had a release and was updated by the normal channels,' and 'was patched at midnight by cowboys'.

[holly-cummins]

s/cowboys/responsible, pragmatic, software engineers/ :)

[gastaldi]

If an extension did a new release, would it change the 'createdAt' or 'updatedAt' field?

It would be a new entry in the extension_release table, so yes, that would have different values

[holly-cummins]

Of course, I forgot that the schema tracks releases, not extensions. Ok, that sounds like a solid plan, then, @gastaldi.

[gastaldi]

@holly-cummins I'll merge this one and investigate the auditing requirements in a separate issue/PR