Roadmap 2023

[natalieparellano]

The current roadmap (https://github.com/buildpacks/community/blob/main/ROADMAP.md) is quite outdated - we should discuss what is still relevant and formulate some new ideas for 2023.

I will add some replies to this thread with things either on the roadmap, or potentially to be added.

Maybe we could also add to each item things that were worked on that support the outcomes mentioned.

[natalieparellano]

Documentation Rework

• Outcomes:
  • Revisit our documentation so it's easier to find the content needed, includes a reference section, and backfill missing topics.

[natalieparellano]

@AidanDelaney could you opine here?

[natalieparellano]

Actually looking through some old notes and #125, I think this was supposed to become:

Onboarding

• Outcomes:
  • Revisit our documentation so it's easier to find the content needed, includes a reference section, and backfill missing topics.
  • Provide more getting started materials.
  • Provide better discoverability of components via the Buildpacks Registry.

[AidanDelaney]

We want to restructure https://buildpacks.io/docs/ so that each of our target audiences has it's own page i.e. move "Application Developers", "Buildpack Authors" and "Platform Operators" to a second level menu. This better allows us to write docs that follow the https://documentation.divio.com/ types for each of our target audiences.

[natalieparellano]

Could buildpacks/rfcs#247 fall under this category?

[AidanDelaney]

Yes, the ongoing saga of buildpacks/rfcs#247 is part of this

[natalieparellano]

Test API

(we intended to remove this from the revised roadmap in mid-2021)

• Outcomes:
  • A specification defining an API for setting up and running tests in a buildpacks-based environment.

[natalieparellano]

@jkutner I believe you had some thoughts around "test buildpacks" that adhere to the existing API. Could you opine please?

[hone]

@natalieparellano I have some strong thoughts on "test buildpacks" as well. I'd like to turn this into a RFC (maybe a collab with Joe). One of the goals to simplify having something for test, would be to just have "test buildpacks" that used the normal buildpack lifecycle to produce "test images". The buildpack author could write a "launch" command that would just execute the tests when the OCI image is run. This would provide the benefit of mostly reproduceable tests and an artifact that could be pulled down and poked out in case the tests failed.

[natalieparellano]

Spec Simplification

• Outcomes:
  • A restructured specification for Cloud Native Buildpacks that is more approachable, and easier to amend.

[natalieparellano]

I am guessing this is still a priority? For updates I might add:

• Things done:
  • RFC for stack removal
  • Creation of distribution spec
  • Deprecated older APIs
• Still to do:
  • Implement stack removal
  • RFC for moving things from platform -> distribution spec
  • Release distribution spec
  • Other things?

[natalieparellano]

Configurability

• Outcomes:
  • Better escape hatches, flexibility, and ways of configuring buildpack builds.
  • Extending project descriptor to support process types, labels, and runtime env vars.
  • Support for Inline Buildpacks.

[natalieparellano]

• Things done:
  • Inline buildpacks
  • Image extensions / Dockerfiles also support this
• Still to do:
  • Extend project descriptor to support process types, labels, and runtime env vars
  • System buildpacks

[natalieparellano]

Stack Buildpacks

• Outcomes:
  • Better support for adding mixins to stacks.
  • Ability for platform authors and stack authors to allow stacks to be customized.

[natalieparellano]

This should probably become something like:

Base Image Extension with Dockerfiles

• Outcomes:
  • Ability for platform authors and base image authors to allow base images to be customized.
• Things done:
  • Merged RFC
  • Implemented build image extension and run image switching
• Still to do:
  • Run image extension
  • Rebase

[natalieparellano]

Develop API

(we intended to remove this from the revised roadmap in mid-2021)

• Outcomes:
  • A specification defining an API for inner-loop development iterations in a buildpacks-based environment.

[hone]

I think the original Develop API is too large in scope. Instead, I'd like to put forward integration with the devcontainers standard instead that is already supported by vscode and codespaces. One of the challenges today is the Develop API requires us to handle a lot of the complications of the container development loop and how developers want to use it. What's exciting to me about devcontainers is that it narrows what we need to solve to producing a development environment. This is something buildpacks already do well for production images. What would doing that for development look like?

[natalieparellano]

Integration with the Cloud Native Ecosystem

• Outcomes:
  • A better out-of-the box Kubernetes and Docker integration story

[natalieparellano]

Better support for ARM / cross platform builds

(not on the existing roadmap but something we've talked about as being important)

[natalieparellano]

• Things done:
  • pack supported on ARM
  • lifecycle supported on ARM
  • Others?
• Still to do:
  • Stack removal will support the cross platform story
  • Some design around the strategies we want to pursue WRT emulation, bare metal, etc. - cc @AidanDelaney
  • There are a couple of pack issues that we can link to
  • Others?

[natalieparellano]

Supply Chain Security

(we intended to add this to the revised roadmap in mid-2021)

[natalieparellano]

• Things done:
  • Standardized SBOM
  • Lifecycle / launcher SBOM
  • Builder env config
  • Others?
• Still to do:
  • Potentially, integration with cosign - @samj1912 did you have any updates on this?
  • Others?

[AidanDelaney]

IMHO Supply Chain Security needs to be one of the higher priority items on our roadmap.

[natalieparellano]

1.0

Ship 1.0 versions of the platform and buildpack specs

• Still to do:
  • Approved RFCs & RFC ideas that are breaking changes: https://github.com/buildpacks/rfcs/issues?q=is%3Aissue+is%3Aopen+label%3Abreaking-change
  • Others?