How should we manage platform api versions

[dwillist]

Summary

For every new field we add to a functional toml file, we will need to add some logic to do the following:

   if (field is set on previous api-version) {
      - zero out the field
      - warn/fail that data that was written by in old api is now functional
   }

Is there a better way to manage the structs that are used to produce toml so that we don't end up having to repeatedly add the above logic

From discussion on 2/11 here

[natalieparellano]

I think at one point this was leading us to consider potentially writing our own TOML parser (or extending an existing parser) to be API-aware.

The opt-in layer caching PR introduced a wrapper around encoding & decoding for a specific file: https://github.com/buildpacks/lifecycle/tree/a7428a55c2a14d8a37e84285b95dc63192e3264e/buildpack/v05

Probably the way we handle this problem will evolve, and common code should eventually be consolidated in one place. However at this point I'm not sure if there is a specific action to take, other than "this is a code refactor we'd like to do over time".

Thoughts?

[natalieparellano]

https://github.com/buildpacks/lifecycle/pull/805 is a first pass at making this more manageable for logic in main / cmd. I plan to put forward a sub-team RFC proposing a lifecycle package organization & services pattern (in the spirit of https://github.com/buildpacks/lifecycle/pull/800) that could help with the lifecycle package.

[natalieparellano]

https://github.com/buildpacks/rfcs/pull/217 proposes some ideas for managing this problem.