This roadmap is the second roadmap for 2023 leading up to KubeCon NA (2023-11-06). For more context on all the changes to roadmaps, see these two RFCs: RFC 0118 and RFC 0121.
Items Continuing from 2023H1
- Owner: @natalieparellano
- Links: RFC, tracking issue
This started out as Stack Buildpacks and is now Dockerfile Extensions. Significant work has already been done on this feature over the last year. This roadmap item is about seeing this work through with releasing phase 3 in both lifecycle and pack.
- Owner: @jkutner
- Links: RFC, tracking issue
This RFC was merged in 2021 and is a dependency on Base Image Extensions. In order to get us to 1.0, we'll need to take on some of these painful backwards breaking changes in the best way possible. This work will include the Buildpack & Platform spec changes with support in lifecycle and pack.
- Owner: @hone
- Links: RFC
There has long been a desire for a "Test" support, but it's never been prioritized even though it's made the roadmap before. Not to be over ambitious, the first step is to get a RFC written and accepted.
- @microwavables (Team Lead sponsor @jkutner)
- Links: VMware Tanzu Community Engagement Health Checks
The project is lucky to have a Community Manager! This is one of the projects proposed by @microwavables to set a base line to measure how we're doing as a community.
- Owner: @joshwlewis (Team Lead sponsor @hone)
- Links: TBD
Currently, Buildpack Authors have little to no tools around visibility with their buildpacks as they run on a platform, including pack. In some of the Heroku v2 buildpacks, they implemented logging that could be handed off to the platform by running bin/report. This work stream is about standardizing output for both successful AND failed builds that Buildpack Authors can use to instrument their buildpack.
- Owner: @jabrown85
- Links: RFC
A platform operator can configure registry mirrors that lifecycle could use without needing for the manifest to have to point to it. This will allow a platform to reduce the risk of service operations from external registry sources and reduce public network bandwidth usage. The resulting image when taken off platform will also function without needing access to the registry mirror.
- Owner: @jjbustamante (Team Lead sponsor @samj1912)
- Links: RFC
kpack is being proposed to be donated as an open source project in the Cloud Native Buildpacks' new Community Organization as a vendor neutral staging ground. This will give the project space to grow the project contributor base from multiple vendors. While work has started on this in H1, this item represents our commitment as a project to see this through and set this project up for success under the CNB governance umbrella.
- Owner: @natalieparellano
- Links: Cosign Integration RFC, SBOM layer RFC,
While CNBs support SBOMs today, they were designed a few years ago and tooling around them have been evolving. This work stream is about making CNBs integrate better with tools like cosign's SBOM spec and the upcoming OCI References feature in OCI Image Manifest 1.1.
- Owner: @jjbustamante (Team Lead sponsor @hone)
- Links: RFC
Multi-arch support has been a highly request feature with the growing popularity of the ARM architecture. In order to better support this with Buildpacks, the first step will be to able to use manifest lists to provide a single URI for Buildpacks that support multiple architectures.
- Owner: @jjbustamante (Team Lead sponsor @natalieparellano)
- Links: RFC
The RFC has been merged and the implementation is expected to be released in experimental mode on pack v0.30.0.