CNB shim defaults to Buildpack API 0.4 which is deprecated

[edmorley]

As of lifecycle 0.16+, any Buildpack API version lower than 0.7 is deprecated. Currently cnb-shim defaults to Buildpack API 0.4, which means warnings like the following can be seen in the pack build output when using heroku/builder-classic:22 - for example:

===> DETECTING
Warning: Buildpack 'heroku/ruby@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/clojure@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/python@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/java@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/gradle@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/scala@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/php@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/go@0.0.0' requests deprecated API '0.4'
Warning: Buildpack 'heroku/nodejs@0.0.0' requests deprecated API '0.4'

Whilst cnb-shim supports overriding the choice of default Buildpack API version via URL parameters (eg &api=0.8), this only updates the API version listed in the generated buildpack.toml, and doesn't actually make the rest of cnb-shim compatible with the newer API versions.

An initial attempt at updating to a newer default Buildpack API version occurred in #66, however that was then reverted in #68 due to #67.

As mentioned in #67 (comment) fixing #67 is non-trivial, since the libbuildpack Go library that cnb-shim uses doesn't support newer Buildpack API versions - and in fact libbuildpack has been sunset in favour of the libcnb Go library, so cnb-shim would need to migrate to a new library.

Lastly, cnb-shim currently doesn't have any concept of supporting multiple buildpack API versions within the wrapper bash scripts or the releaser Go binary. So if we change cnb-shim to be compatible with newer Buildpack API versions, we'll then break compatibility with users specifying an older API version - unless we add support for multiple API versions, or decide to only support a single API version (which may not be viable, given users of the web service have no way to control when the service is updated).

All of these means we may want/need to reconsider the design/maintainability of cnb-shim longer term as part of trying to solve this issue.

GUS-W-13062656.

[edmorley]

The upstream CNB project is going to be releasing lifecycle 0.18.0 shortly. This new version drops support for the deprecated platform and buildpack API versions:
https://github.com/buildpacks/lifecycle/pull/1218/files?short_path=b335630#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

This means any buildpack API version less than 0.7 will no longer be supported (once we update the Heroku builder images to use the new lifecycle release) - making cnb-shim no longer supported, unless it's upgraded/fixed.

Whilst we can probably hold off updating lifecycle in our builder images for a little bit, at some point we're going to have no choice but to update (e.g. needing new buildpack API features or lifecycle fixes).

[edmorley]

lifecycle 0.18.0 (that drops support for the Buildpack API version currently used by cnb-shim) is now out:
https://github.com/buildpacks/lifecycle/releases/tag/v0.18.0

[edmorley]

Noting here for completeness: The main heroku/builder:* Heroku CNB builder images were upgraded to lifecycle 0.18.0 in November 2023 (in heroku/cnb-builder-images#431), since we couldn't wait any longer for cnb-shim to be modernised, so the cnb-shim hasn't worked with those builders since then. There has not been a single user notice or mention that cnb-shim no longer worked; it's usage is clearly non-existent outside of shimming the classic buildpacks in the older per-native-cnb builder images.