Merge branch 'main' into more-extensions

Author: Natalie Arellano

content/docs/app-developer-guide/run-an-app.md

@@ -50,6 +50,8 @@ Base Image:
 Run Images:
   cnbs/sample-stack-run:alpine
 
+Rebasable: true
+
 Buildpacks:
   ID                             VERSION           HOMEPAGE
   samples/java-maven             0.0.1             https://github.com/buildpacks/samples/tree/main/buildpacks/java-maven

content/docs/app-developer-guide/using-cache-image.md

@@ -85,4 +85,12 @@ pack build localhost:5000/buildpack-examples/second-cache-image-example \
 ```
 <!--+- "{{execute}}"+-->
 
+### Image Retention
+
+Managing the lifecycle of images should be the responsibility of the owner, as `the platform does not automatically clean up old images from the registry`.   
+You can refer to your registry's documentation to learn how to accomplish this.   
+* [AWS ECR](https://aws.amazon.com/ecr/) users can find information on how to delete images in the AWS ECR documentation, specifically in the section on [image deletion](https://docs.aws.amazon.com/AmazonECR/latest/userguide/delete_image.html).
+* [Docker](https://docs.docker.com/engine/) users can consult the Docker documentation on [Advanced Image Management](https://docs.docker.com/docker-hub/image-management/) to find out how to delete images.
+
+
 [samples]: https://github.com/buildpack/samples

content/docs/buildpack-author-guide/create-buildpack/adding-bill-of-materials.md

@@ -10,6 +10,7 @@ One of the benefits of buildpacks is they can also populate the app image with m
 * The process types that are available and the commands associated with them
 * The run-image the app image was based on
 * The buildpacks were used to create the app image
+* Whether the run-image can be rebased with a new version through the `Rebasable` label or not
 * And more...!
 
 You can find some of this information using `pack` via its `inspect-image` command.  The bill-of-materials information will be available using `pack sbom download`.

content/docs/features/dockerfiles.md

@@ -56,8 +56,7 @@ An image extension could be defined with the following directory:
 * `./bin/detect` is invoked during the `detect` phase. It analyzes application source code to determine if the extension
   is needed and contributes build plan entries.
 * `./bin/generate` is invoked during the `generate` phase (a new lifecycle phase that happens after `detect`). It
-  outputs either or both of `build.Dockerfile` or `run.Dockerfile` for extending the builder or run image,
-  respectively (in the [initial implementation](#phased-approach), only limited `run.Dockerfile`s are allowed).
+  outputs either or both of `build.Dockerfile` or `run.Dockerfile` for extending the builder or run image.
 
 For more information and to see a build in action,
 see [authoring an image extension](/docs/extension-guide/create-extension).
@@ -78,30 +77,9 @@ should be **used with great care**. Platform operators should be mindful that:
   may not have all the mixins required by buildpacks that detected. Platforms may wish to optionally re-validate mixins
   prior to `build` when using extensions.
 
-### Phased approach
+### Putting it all together
 
-Some limitations of the initial implementation of the Dockerfiles feature have already been mentioned, and we'll expand
-on them here. As this is a large and complicated feature, the implementation has been split into phases in order to
-deliver incremental value and gather feedback.
-
-#### Phase 1 (supported in lifecycle `0.15.0` or greater)
-
-One or more `run.Dockerfile`s each containing a single `FROM` instruction can be used to switch the original run image
-to a new image (as no image modifications are permitted, there is no need to run `extend` on the run image)
-
-#### Phase 2 (supported in lifecycle `0.15.0` or greater)
-
-One or more `build.Dockerfile`s can be used to extend the builder image
-
-* A new `extend` lifecycle phase is introduced to apply `build.Dockerfile`s from `generate` to the builder image
-
-#### Phase 3 (future)
-
-One or more `run.Dockerfile`s can be used to extend the run image
-
-* The `extend` lifecycle phase can be run in parallel for the builder and run images
-
-The final ordering of lifecycle phases will look something like the following:
+The ordering of lifecycle phases looks like the following:
 
 * `analyze`
 * `detect` - after standard detection, `detect` will also run extensions' `./bin/generate`; output Dockerfiles are
@@ -116,9 +94,9 @@ For more information, consult the [migration guide](/docs/reference/spec/migrati
 
 #### Platform support for Dockerfiles
 
-Supported (phases 1 and 2):
+Supported:
 
-* [pack cli](https://github.com/buildpacks/pack) (version `0.28.0` and above)
+* [pack cli](https://github.com/buildpacks/pack) (prefer version `0.30.0` and above)
 
 Needs support:
 

katacoda/scenarios/app-developer-guide/run-an-app.md

@@ -42,6 +42,8 @@ Base Image:
 Run Images:
   cnbs/sample-stack-run:alpine
 
+Rebasable: true
+
 Buildpacks:
   ID                             VERSION           HOMEPAGE
   samples/java-maven             0.0.1             https://github.com/buildpacks/samples/tree/main/buildpacks/java-maven