Merge branch 'main' into restore-checks-sha

.github/workflows/test-s390x.yml

@@ -68,8 +68,8 @@ jobs:
           script: |
             apt-get update -y
             apt-get install -y wget curl git make gcc jq docker.io
-            wget https://go.dev/dl/go1.22.2.linux-s390x.tar.gz
-            rm -rf /usr/local/go && tar -C /usr/local -xzf go1.22.2.linux-s390x.tar.gz
+            wget https://go.dev/dl/go1.23.2.linux-s390x.tar.gz
+            rm -rf /usr/local/go && tar -C /usr/local -xzf go1.23.2.linux-s390x.tar.gz
             export PATH=$PATH:/usr/local/go/bin
             git clone ${GH_REPOSITORY} lifecycle
             cd lifecycle && git checkout ${GH_REF}

Makefile

@@ -30,7 +30,7 @@ LDFLAGS+=-X 'github.com/buildpacks/lifecycle/cmd.Version=$(LIFECYCLE_VERSION)'
 GOBUILD:=go build $(GOFLAGS) -ldflags "$(LDFLAGS)"
 GOTEST=$(GOCMD) test $(GOFLAGS)
 BUILD_DIR?=$(PWD)$/out
-WINDOWS_COMPILATION_IMAGE?=golang:1.22-windowsservercore-1809
+WINDOWS_COMPILATION_IMAGE?=golang:1.23-windowsservercore-1809
 SOURCE_COMPILATION_IMAGE?=lifecycle-img
 BUILD_CTR?=lifecycle-ctr
 DOCKER_CMD?=make test

RELEASE.md

@@ -1,22 +1,73 @@
-## Release Finalization
+# Release Finalization
 
-To cut a pre-release:
+## Types of releases
+
+#### New minor
+* For newly supported Platform or Buildpack API versions, or breaking changes (e.g., API deprecations).
+
+#### Pre-release aka release candidate
+* Ideally we should ship a pre-release (waiting a few days for folks to try it out) before we ship a new minor.
+* We typically don't ship pre-releases for patches or backports.
+
+#### New patch
+* For go version updates, CVE fixes / dependency bumps, bug fixes, etc.
+* Review the latest commits on `main` to determine if any are unacceptable for a patch - if there are commits that should be excluded, branch off the latest tag for the current minor and cherry-pick commits over.
+
+#### Backport
+* New patch for an old minor. Typically, to help folks out who haven't yet upgraded from [unsupported APIs](https://github.com/buildpacks/rfcs/blob/main/text/0110-deprecate-apis.md).
+* For go version updates, CVE fixes / dependency bumps, bug fixes, etc.
+* Branch off the latest tag for the desired minor.
+
+## Release Finalization Steps
+
+### Step 1 - Prepare
+
+Determine the type of release ([new minor](#new-minor), [pre-release](#pre-release-aka-release-candidate), [new patch](#new-patch), or [backport](#backport)) and prepare the branch accordingly.
+
+**To prepare the release branch:**
+1. Check open PRs for any dependabot updates that should be merged.
+1. Create a release branch in the format `release/0.99.0-rc.1` (for pre-releases) or `release/0.99.0` (for final releases).
+   * New commits to this branch will trigger the `build` workflow and produce a lifecycle image: `buildpacksio/lifecycle:<commit sha>`.
 1. If applicable, ensure the README is updated with the latest supported apis (example PR: https://github.com/buildpacks/lifecycle/pull/550).
-1. Create a release branch in the format `release/0.99.0-rc.1`. New commits to this branch will trigger the `build` workflow and produce a lifecycle image: `buildpacksio/lifecycle:<commit sha>`.
-1. When ready to cut the release, manually trigger the `draft-release` workflow: Actions -> draft-release -> Run workflow -> Use workflow from branch: `release/0.99.0-rc.1`. This will create a draft release on GitHub using the artifacts from the `build` workflow run for the latest commit on the release branch.
-1. Edit the release notes as necessary.
-1. Perform any manual validation of the artifacts.
-1. When ready to publish the release, edit the release page and click "Publish release". This will trigger the `post-release` workflow that will re-tag the lifecycle image from `buildpacksio/lifecycle:<commit sha>` to `buildpacksio/lifecycle:0.99.0` but will NOT update the `latest` tag.
+   * For final releases (not pre-releases), remove the pre-release note (`*`) for the latest apis.
 
-To cut a release:
+**For final releases (not pre-releases):**
 1. Ensure the relevant spec APIs have been released.
 1. Ensure the `lifecycle/0.99.0` milestone on the [docs repo](https://github.com/buildpacks/docs/blob/main/RELEASE.md#lump-changes) is complete, such that every new feature in the lifecycle is fully explained in the `release/lifecycle/0.99` branch on the docs repo, and [migration guides](https://github.com/buildpacks/docs/tree/main/content/docs/reference/spec/migration) (if relevant) are included.
-1. Create a release branch in the format `release/0.99.0`. New commits to this branch will trigger the `build` workflow and produce a lifecycle image: `buildpacksio/lifecycle:<commit sha>`.
-1. If applicable, ensure the README is updated with the latest supported apis (example PR: https://github.com/buildpacks/lifecycle/pull/550) and remove the pre-release note for the latest apis.
-1. When ready to cut the release, manually trigger the `draft-release` workflow: Actions -> draft-release -> Run workflow -> Use workflow from branch: `release/0.99.0`. This will create a draft release on GitHub using the artifacts from the `build` workflow run for the latest commit on the release branch.
+
+### Step 2 - Publish the Release
+
+1. Manually trigger the `draft-release` workflow: Actions -> draft-release -> Run workflow -> Use workflow from branch: `release/<release version>`. This will create a draft release on GitHub using the artifacts from the `build` workflow run for the latest commit on the release branch.
 1. Edit the release notes as necessary.
-1. Perform any manual validation of the artifacts.
-1. When ready to publish the release, edit the release page and click "Publish release". This will trigger the `post-release` workflow that will re-tag the lifecycle image from `buildpacksio/lifecycle:<commit sha>` to `buildpacksio/lifecycle:0.99.0` and `buildpacksio/lifecycle:latest`.
-1. Once released
-- Update the `main` branch to remove the pre-release note in [README.md](https://github.com/buildpacks/lifecycle/blob/main/README.md) and/or merge `release/0.99.0` into `main`.
-- Ask the learning team to merge the `release/lifecycle/0.99` branch into `main` on the docs repo.
+1. Perform any manual validation of the artifacts as necessary (usually none).
+1. Edit the release page and click "Publish release".
+   * This will trigger the `post-release` workflow that will re-tag the lifecycle image from `buildpacksio/lifecycle:<commit sha>` to `buildpacksio/lifecycle:<release version>`.
+     * For final releases ONLY, this will also re-tag the lifecycle image from `buildpacksio/lifecycle:<commit sha>` to `buildpacksio/lifecycle:latest`.
+
+### Step 3 - Follow-up
+
+**For pre-releases:**
+* Ask the relevant teams to try out the pre-released artifacts.
+
+**For final releases:**
+* Update the `main` branch to remove the pre-release note in [README.md](https://github.com/buildpacks/lifecycle/blob/main/README.md) and/or merge `release/0.99.0` into `main`.
+* Ask the learning team to merge the `release/lifecycle/0.99` branch into `main` on the docs repo.
+
+## Go version updates
+
+Go version updates should be released as a [new minor](#new-minor) or [new patch](#new-patch) release.
+
+### New Patch
+
+If the go patch is in [actions/go-versions](https://github.com/actions/go-versions/pulls?q=is%3Apr+is%3Aclosed) then CI should pull it in automatically without any action needed.
+We simply need to create the release branch and let the pipeline run.
+
+### New Minor
+
+We typically do this when the existing patch version exceeds 6 - e.g., `1.22.6`. This means we have about 6 months to upgrade before the current minor becomes unsupported due to the introduction of the new n+2 minor.
+
+#### Steps
+1. Update go.mod
+1. Search for the old `major.minor`, there are a few files that need to be updated (example PR: https://github.com/buildpacks/lifecycle/pull/1405/files)
+1. Update the linter to a version that supports the current `major.minor`
+1. Fix any lint errors as necessary

acceptance/testdata/launcher/Dockerfile

@@ -1,4 +1,4 @@
-FROM golang:1.22 as builder
+FROM golang:1.23 as builder
 
 COPY exec.d/ /go/src/exec.d
 RUN GO111MODULE=off go build -o helper ./src/exec.d

acceptance/testdata/launcher/Dockerfile.windows

@@ -1,4 +1,4 @@
-FROM golang:1.22-nanoserver-1809
+FROM golang:1.23-nanoserver-1809
 
 COPY exec.d/ /go/src/exec.d
 WORKDIR /go/src

go.mod

@@ -139,4 +139,4 @@ require (
 	google.golang.org/protobuf v1.34.1 // indirect
 )
 
-go 1.22
+go 1.23