Deprecate non-specification field

[ForestEckhardt]

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[ryanmoran]

It may not appear to be used in packit or by our buildpacks, but jam uses this field here. Maybe we can figure out how not to use this in jam and then we can remove it.

[ForestEckhardt]

Interesting because as far as I can figure from the spec the buildpack table has no SHA field. I'll take a look!

[ryanmoran]

Its not used to read out a value from the buildpack.toml. Its just used to hold the value between that point in the jam code and the formatter.

[ForestEckhardt]

@ryanmoran Here is a PR to remove the use of the Buildpack.SHA256 field from jam paketo-buildpacks/jam#17

[ryanmoran]

Are you planning to bump the major version of packit when you remove this?

[ForestEckhardt]

I hadn't really thought about how I would classify the bump. I think that by definition it would have to be but the field was never parsed it was just part of the structure. It feels a little silly to have a major bump over such a small change.

[ryanmoran]

Yes. But strictly speaking, its a backwards-incompatible change. Maybe you should leave the field and just mark it as deprecated which is what we have done in the past. Then, when we get to a point where a major version bump feels warranted because of other, more substantial changes, we can remove it.

[ForestEckhardt]

I think that is fair. We can still go forward with the Jam change as well.