turkdevops · pull · Jul 15, 2025 · Jan 26, 2023 · Jan 27, 2023 · Jan 31, 2023
diff --git a/.github/auto-assign-bat.yml b/.github/auto-assign-bat.yml
@@ -8,4 +8,4 @@ filterLabels:
 assignees:
 - ekcasey
 - hone
-- samj1912
+- sambhav
diff --git a/.github/auto-assign-learning.yml b/.github/auto-assign-learning.yml
@@ -8,4 +8,3 @@ filterLabels:
 assignees:
 - jkutner
 - jromero
-- samj1912
diff --git a/.github/workflows/auto-assign-maintainer.yml b/.github/workflows/auto-assign-maintainer.yml
@@ -14,7 +14,7 @@ jobs:
     runs-on:
     - ubuntu-latest
     steps:
-    - uses: kentaro-m/auto-assign-action@v1.2.4
+    - uses: kentaro-m/auto-assign-action@v1.2.5
       with:
         configuration-path: .github/auto-assign-core.yml
   distribution:
@@ -23,7 +23,7 @@ jobs:
     runs-on:
     - ubuntu-latest
     steps:
-    - uses: kentaro-m/auto-assign-action@v1.2.4
+    - uses: kentaro-m/auto-assign-action@v1.2.5
       with:
         configuration-path: .github/auto-assign-distribution.yml
   implementation:
@@ -32,7 +32,7 @@ jobs:
     runs-on:
     - ubuntu-latest
     steps:
-    - uses: kentaro-m/auto-assign-action@v1.2.4
+    - uses: kentaro-m/auto-assign-action@v1.2.5
       with:
         configuration-path: .github/auto-assign-implementation.yml
   learning:
@@ -41,7 +41,7 @@ jobs:
     runs-on:
     - ubuntu-latest
     steps:
-    - uses: kentaro-m/auto-assign-action@v1.2.4
+    - uses: kentaro-m/auto-assign-action@v1.2.5
       with:
         configuration-path: .github/auto-assign-learning.yml
   platform:
@@ -50,7 +50,7 @@ jobs:
     runs-on:
     - ubuntu-latest
     steps:
-    - uses: kentaro-m/auto-assign-action@v1.2.4
+    - uses: kentaro-m/auto-assign-action@v1.2.5
       with:
         configuration-path: .github/auto-assign-platform.yml
   bat:
@@ -59,6 +59,6 @@ jobs:
     runs-on:
       - ubuntu-latest
     steps:
-      - uses: kentaro-m/auto-assign-action@v1.2.4
+      - uses: kentaro-m/auto-assign-action@v1.2.5
         with:
           configuration-path: .github/auto-assign-bat.yml
diff --git a/.github/workflows/issues-generation.yml b/.github/workflows/issues-generation.yml
@@ -15,7 +15,7 @@ jobs:
     if: ${{ github.event.issue.pull_request || github.event.pull_request }}
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Run Issue Generation
         uses: jromero/issue-generation-action@v1.0.0-beta.4
         id: issues-generation

diff --git a/README.md b/README.md
@@ -45,12 +45,13 @@ Once an RFC has been accepted, the sub-team maintainers should:
 Once an `issues-created/<sub-team>` label has been created for each sub-team, the RFC is ready to merge. The team member who merges the pull request should do the following:
 
 1. Assign an id based off the pull request number.
-1. Rename the file based off the ID inside `text/`.
-1. Fill in the remaining metadata at the top.
-1. Commit everything.
-1. Update issues with RFC ID and a link to the text file.
-1. Update any links in PR description to point at the committed file.
-1. Remove the "Final Comment Period" label.
+2. Rename the file based off the ID inside `text/`.
+3. Fill in the remaining metadata at the top.
+4. Commit everything.
+5. Update issues with RFC ID and a link to the text file.
+6. Update any links in PR description to point at the committed file.
+7. Remove the "status/voting" label.
+8. Create a [tracking issue](https://github.com/buildpacks/rfcs/issues/new?assignees=&labels=type%2Ftracking&template=tracking.md&title=%5BRFC+%23%3CINSERT+RFC+NUMBER+-+e.g.%2C+0099%3E%5D+-+%3CINSERT+RFC+TITLE%3E).
 
 ## Automation
 
@@ -60,4 +61,6 @@ The `merge-rfc.sh` script automates several steps of the merge process for accep
 ```
 Each `<issue>` should be of the form `<org>/<repo>#<number>` (e.g. `buildpacks/spec#1`). In the rare case that no work must be done in the project as a result of the RFC pass the `-n` flag to explicitly indicate that no issues should be linked.
 
-After running the `merge-rfc.sh` script, manually verify the output before pushing changes.
+After running the `merge-rfc.sh` script:
+* Manually verify the output before pushing changes.
+* Create a [tracking issue](https://github.com/buildpacks/rfcs/issues/new?assignees=&labels=type%2Ftracking&template=tracking.md&title=%5BRFC+%23%3CINSERT+RFC+NUMBER+-+e.g.%2C+0099%3E%5D+-+%3CINSERT+RFC+TITLE%3E).
diff --git a/merge-rfc.sh b/merge-rfc.sh
@@ -50,13 +50,6 @@ require_command() {
 
 require_command git
 require_command jq
-require_command issues-generation
-
-if [[ -z "${GITHUB_TOKEN:-}" ]]; then
-  require_command op
-  echo "> Pulling GitHub token from vault..."
-  GITHUB_TOKEN=$(op read op://Shared/7xorpxvz3je3vozqg3fy3wrcg4/credential --account buildpacks)
-fi
 
 ####
 # INPUTS / VALIDATION
@@ -107,25 +100,13 @@ fi
 RFC_ID=$(generate_id)
 echo "> Generated RFC number: ${RFC_ID}"
 
-echo "> Creating issues for PR#${PR_NUMBER}"
-export GITHUB_TOKEN
-
-issues-generation create --pr "${OWNER}/${REPO}#${PR_NUMBER}" --bot $BOT_USERNAME  --prepend "[RFC #${RFC_ID}] "
-ISSUES_TO_LINK=$(issues-generation list --pr "${OWNER}/${REPO}#${PR_NUMBER}" --bot $BOT_USERNAME --json | jq -r '[.[] | select(.num) | .repo + "#" + (.num|tostring) ] | join(" ")')
-
-for ISSUE in ${ISSUES_TO_LINK}; do
-  if [[ $ISSUES_TEXT == "N/A" ]]; then
-    ISSUES_TEXT=$(link_issue "$ISSUE")
-  else
-    ISSUES_TEXT+=", $(link_issue "$ISSUE")"
-  fi
-done
-
-
 if [[ $NO_ISSUES = false && $ISSUES_TEXT == "N/A" ]]; then
-  echo -e "ERROR! No issues were provided. Are you sure there are no issues that should be linked?"
-  echo -e "ERROR! Either -i or -n is required\n"
-  usage
+  echo "> Please create an issue by following the link below:"
+  echo "https://github.com/buildpacks/rfcs/issues/new?assignees=&labels=type%2Ftracking&projects=&template=tracking.md&title=%5BRFC+%23${RFC_ID}%5D+%3C+-+INSERT+RFC+TITLE%3E"
+  echo ""
+  read -p "Press Enter to continue" </dev/tty
+
+  read -p "> Please enter the issue link: " ISSUES_TEXT
 fi
 
 echo "> Pulling latest changes...."

diff --git a/text/0041-api-version-compat.md b/text/0041-api-version-compat.md
@@ -43,7 +43,7 @@ The spec will use future `0.x` API releases to include any desired changes with
 This RFC does not make changes to the API compatibility rules post 1.0. 1.x APIs version are stil assumed to be purely additive.
 
 ## Lifecycle
-The lifecycle will use the [lifecycle descriptor](https://github.com/buildpacks/rfcs/blob/pack-publish-buildpack/text/0011-lifecycle-descriptor.md)
+The lifecycle will use the [lifecycle descriptor](https://github.com/buildpacks/rfcs/blob/main/text/0011-lifecycle-descriptor.md)
 to indicate the implemented API versions as before. However, the compatibility assumptions will change.
 It will be assumed that a lifecycle declaring support for the `0.x` version of the API, supports all 0.2-0.x API versions.
 

diff --git a/text/0078-group-additions.md b/text/0078-group-additions.md
@@ -3,7 +3,7 @@
 - Name: Group additions to Builder order
 - Start Date: 2020-12-23
 - Author(s): [jkutner](@jkutner)
-- Status: Implemented
+- Status: Approved
 - RFC Pull Request: [rfcs#129](https://github.com/buildpacks/rfcs/pull/129)
 - CNB Pull Request: (leave blank)
 - CNB Issue: [buildpacks/docs#319](https://github.com/buildpacks/docs/issues/319), [buildpacks/pack#1099](https://github.com/buildpacks/pack/issues/1099), [buildpacks/pack#1100](https://github.com/buildpacks/pack/issues/1100), [buildpacks/spec#195](https://github.com/buildpacks/spec/issues/195)

diff --git a/text/0093-remove-shell-processes.md b/text/0093-remove-shell-processes.md
@@ -108,7 +108,7 @@ Using the new API this process could look like:
 ```
 [[processes]]
 type = "bash"
-command = ["-c", "dotnet", "my-app.dll", "--urls", "http://0.0.0.0:${PORT:-8080}"]
+command = ["bash", "-c", "dotnet", "my-app.dll", "--urls", "http://0.0.0.0:${PORT:-8080}"]
 default = true
 ```
 Things to note:
@@ -400,4 +400,4 @@ In addition to the changes described originally in 0093 we'd like some way of ve
 
 Why was this amendment necessary?
 
-The RFC text should reflect what was actually implemented / agreed upon to avoid confusion.
+The RFC text should reflect what was actually implemented / agreed upon to avoid confusion.
diff --git a/text/0096-remove-stacks-mixins.md b/text/0096-remove-stacks-mixins.md
@@ -41,26 +41,26 @@ Instead of a stack ID, runtime and build-time base images must contain the follo
 - OS (e.g., "linux", `$GOOS`), specified as `os` in the base image `config` 
 - Architecture (e.g., "arm", `$GOARCH`), specified as `architecture` in the base image `config`
 - Architecture Variant (optional) (e.g., "v6", `$GOARM`), specified as `variant` in the base image `config`
-- Distribution (optional) (e.g., "ubuntu", `$ID`), specified as a label `io.buildpacks.distribution.name`
-- Version (optional) (e.g., "18.04", `$VERSION_ID`), specified as a label `io.buildpacks.distribution.version`
+- Distribution (optional) (e.g., "ubuntu", `$ID`), specified as a label `io.buildpacks.base.distro.name`
+- Version (optional) (e.g., "18.04", `$VERSION_ID`), specified as a label `io.buildpacks.base.distro.version`
 
 Additionally, the runtime base may contain the following metadata:
-- Target ID (optional) (e.g., "minimal"), specified as a label `io.buildpacks.id`
+- Target ID (optional) (e.g., "minimal"), specified as a label `io.buildpacks.base.id`
 
 OS, Architecture, and Architecture Variant must be valid identifiers as defined in the [OCI Image specification](https://github.com/opencontainers/image-spec/blob/main/config.md).
 
 Target ID is an identifier specified on the runtime base image that must be provided to buildpacks as `CNB_TARGET_ID` during the build process.
 This allows buildpacks to change their behavior if a run image is selected (e.g., distroless) that has special properties outside of OS, architecture, etc.
 
 For Linux-based images, each field should be canonicalized against values specified in `/etc/os-release` (`$ID` and `$VERSION_ID`).
-The `os.version` field in an base image `config` may contain combined distribution and version information, but it is not used by the lifecycle.
+The `os.version` field in a base image `config` may contain combined distribution and version information, but it is not used by the lifecycle.
 
 For Windows-based images, Distribution should be empty. Version should be the [suggested value of `os.version`](https://github.com/opencontainers/image-spec/blob/main/config.md#properties) in the OCI spec (e.g., `10.0.14393.1066`).
 
 The `stacks` list in `buildpack.toml` is replaced by a `targets` list, where each entry corresponds to a different buildpack image that is exported into a [manifest index](https://github.com/opencontainers/image-spec/blob/master/image-index.md).
 Each entry may contain multiple valid values for Distribution and/or Version, but only a single OS, Architecture, and Variant.
-If the `targets` list is empty and `/bin/build` is present, a target with `os = "linux"` and `arch = "x86_64"` is assumed by tools reading `buildpack.toml`.
-If the `targets` list is empty and `/bin/build.bat` or `/bin/build.exe` is present, a target with `os = "windows"` and `arch = "x86_64"` is assumed by tools reading `buildpack.toml`.
+If the `targets` list is empty and `/bin/build` is present, a target with `os = "linux"` and `arch = "amd64"` is assumed by tools reading `buildpack.toml`.
+If the `targets` list is empty and `/bin/build.bat` or `/bin/build.exe` is present, a target with `os = "windows"` and `arch = "amd64"` is assumed by tools reading `buildpack.toml`.
 
 App image builds fail if the build image and selected run image have mismatched metadata. We may introduce flags or additional labels to skip this validation (e.g., for cross-compilation or minimal runtime base images).
 An image without a specified Distribution is compatible with images specifying any Distribution.
@@ -73,25 +73,25 @@ When an app image is rebased, `rebaser` must fail if the new run image and previ
 ```toml
 [[targets]]
 os = "linux"
-arch = "x86_64"
+arch = "amd64"
 [[targets.distributions]]
 name = "ubuntu"
 versions = ["18.04", "20.04"]
 
 [[targets]]
 os = "linux"
-arch = "x86_64"
-[[targets.distributions]]
+arch = "amd64"
+[[targets.distros]]
 name = "ubuntu"
-versions = ["14.04", "16.04"]
+version = "16.04"
 
 [[targets]]
 os = "linux"
 arch = "arm"
 variant = "v6"
-[[targets.distributions]]
+[[targets.distros]]
 name = "ubuntu"
-versions = ["14.04", "16.04"]
+version = "16.04"
 ```
 
 ## Runtime Metadata
@@ -152,12 +152,12 @@ If the newly-specified field values are missing, the lifecycle and pack may used
 
 ```
 config.os = "linux"
-config.architecture = "x86_64"
-io.buildpacks.distribution.name = "ubuntu"
-io.buildpacks.distribution.version = "18.04"
+config.architecture = "amd64"
+io.buildpacks.base.distro.name = "ubuntu"
+io.buildpacks.base.distro.version = "18.04"
 ```
 
-Moving forward it's encouraged for buildpack authors to support both `[[stacks]]` and `[[targets]]` sections in `buildpack.toml` for maximum compatibility. In order to ease this process for those using the `io.buildpacks.stacks.bionic`, lifecycle will translate any section that sets this as on of the `stacks`:
+Moving forward it's encouraged for buildpack authors to support both `[[stacks]]` and `[[targets]]` sections in `buildpack.toml` for maximum compatibility. In order to ease this process for those using the `io.buildpacks.stacks.bionic`, lifecycle will translate any section that sets this as one of the `stacks`:
 
 ```toml
 [[stacks]]
@@ -169,8 +169,8 @@ to
 ```toml
 [[targets]]
 os = "linux"
-arch = "x86_64"
-[[targets.distributions]]
+arch = "amd64"
+[[targets.distros]]
 name = "ubuntu"
 versions = ["18.04"]
 ```
@@ -201,3 +201,32 @@ versions = ["18.04"]
 [spec-changes]: #spec-changes
 
 This RFC requires extensive changes to all specifications.
+
+## Amended
+### Summary
+
+rename x86_64 -> amd64 in keeping with all other usages of arch. descriptors.
+
+### Motivation
+
+This is how we do it everywhere else, this is the way.
+
+## Amended
+### Meta
+[meta-1]: #meta-1
+- Name: Rename Docker labels and `buildpack.toml` table names
+- Start Date: 2024-04-08
+- Author(s): @edmorley
+- Amendment Pull Request: [rfcs#310](https://github.com/buildpacks/rfcs/pull/310)
+
+### Summary
+
+Changes were made to the Docker label and `buildpack.toml` table names between when this RFC was written and the changes were made to the spec in [spec#365](https://github.com/buildpacks/spec/pull/365), which have now been backported to the RFC:
+
+- The `io.buildpacks.distributions.*` Docker labels were renamed to `io.buildpacks.base.distro.*`.
+- The `io.buildpacks.id` Docker label was renamed to `io.buildpacks.base.id`.
+- The `buildpack.toml` table `[[targets.distributions]]` was renamed to `[[targets.distros]]` and the `versions` field within it renamed to `version` (along with its type changing from an array to a string).
+
+### Motivation
+
+To prevent use of the wrong Docker label or `buildpack.toml` table names, if users base their implementations on the RFC rather than reading the spec.
diff --git a/text/0109-build-config.md b/text/0109-build-config.md
@@ -12,7 +12,7 @@
 # Summary
 [summary]: #summary
 
-This RFC proposes an easy way to configure build images to allow specifying a `/cnb/config/env.build` CNB environment directory that allows updating the Buildpack `detect` and `build` environment based on the directory.
+This RFC proposes an easy way to configure build images to allow specifying a `/cnb/build-config` CNB environment directory that allows updating the Buildpack `detect` and `build` environment based on the directory.
 
 
 # Definitions
@@ -40,10 +40,10 @@ The environment variables may ideally also take precendence over any user provid
 # What it is
 [what-it-is]: #what-it-is
 
-The RFC proposes the introduction of the following directory `/cnb/config/env.build` in build images. The directory follows the same convention as a `CNB environment directory`. The notable difference is that the environment variables sourced from this directory are applied **AFTER** processing the user-provided platform environment variables i.e. they should have the highest precedence. These variables should be available during both `detect` and `build` phases (and the `generate` phase in the future).
+The RFC proposes the introduction of the following directory `/cnb/build-config/env` in build images. The directory follows the same convention as a `CNB environment directory`. The notable difference is that the environment variables sourced from this directory are applied **AFTER** processing the user-provided platform environment variables i.e. they should have the highest precedence. These variables should be available during both `detect` and `build` phases (and the `generate` phase in the future).
 
 
-The operator can define this directory in the build image under `/cnb/config` or `CNB_CONFIG_DIR` if defined.
+The operator can define this directory in the build image under `/cnb/build-config` or `CNB_BUILD_CONFIG_DIR` if defined.
 
 # How it Works
 [how-it-works]: #how-it-works
@@ -58,7 +58,7 @@ Final value: `FOO=test`
 
 
 Buildpack value: `FOO=test`
-Build config: `FOO.append=another-value, FOO.delim="`
+Build config: `FOO.append=another-value, FOO.delim=:`
 Final value: `FOO=test:another-value`
 
 Buildpack value: `FOO=test`
@@ -118,5 +118,5 @@ N/A
 
 Addition of the definition of the above directory in the Platform specification i.e. - 
 
-- `CNB_CONFIG_DIR`
-- `/cnb/config/env.build`
+- `CNB_BUILD_CONFIG_DIR`
+- `/cnb/build-config/`
-Original file line number
+Diff line change
@@ Expand Up / @@ -8,4 +8,4 @@ filterLabels: @@
     assignees:
     - ekcasey
     - hone
-    - samj1912
+    - sambhav