Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# Meta
[meta]: #meta
- Name: Deprecate and Remove Windows Support in Binary Buildpack
- Start Date: 2025-01-15
- Author(s): @tnikolova82, @ivanovac, @beyhan
- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
- RFC Pull Request: (fill in with PR link after you submit it)
- Related RFCs: [RFC-0050 Java Buildpack Migration to Golang](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0050-java-buildpack-migration-to-golang.md)

## Summary

Deprecate and immediately remove Windows support from the Cloud Foundry Binary Buildpack. [`v1.1.21`](https://github.com/cloudfoundry/binary-buildpack-release/releases/tag/v1.1.21) will be the last release shipping Windows support. The next release will be Linux-only.

## Problem

- The Windows support in the Binary Buildpack is effectively unmaintained following the departure of its core maintainer from the CF community.
- It is one of the only buildpacks (alongside [`hwc-buildpack`](https://github.com/cloudfoundry/hwc-buildpack)) supporting Windows, and the current maintainers have no Windows experience to support this use case.
- No one has stepped up to maintain the Windows portion despite calls for help.
- Shipping a Windows binary that maintainers cannot audit, patch, or verify is a risk that should not be prolonged.

## What is being deprecated

The Binary Buildpack's Windows support enables deploying pre-compiled Windows executables (e.g. `.exe`, `.bat` entrypoints) to Cloud Foundry Windows Diego cells. Concretely, the following pieces are being removed:

- The `binary-buildpack-windows` package: the BOSH release currently ships two packages — a Linux-compiled buildpack binary and a separate Windows-compiled buildpack binary. When CF schedules an app onto a Windows cell, the Windows variant is used as the buildpack runtime to detect, supply, and launch the app's binary. Only the Linux package will remain.
- The `windows` stack entry in `binary-buildpack-release`'s `manifest.yml` and the corresponding job/packaging specs that wire the Windows package into the BOSH release.
- Windows-specific buildpack code in [`binary-buildpack`](https://github.com/cloudfoundry/binary-buildpack), including:
- Files guarded by `//go:build windows` build tags (e.g. Windows-specific `finalize`/`supply` and launcher logic).
- Handling for Windows-style start commands and executable extensions (`.exe`, `.bat`).
- Windows-targeted packaging scripts and any `GOOS=windows` cross-compilation in build tooling.
- Windows CI: GitHub Actions / Concourse jobs that cross-compile, unit test, and integration-test the buildpack against Windows cells (including any `cflinuxfs*` ↔ `windows*` matrix entries).
- Windows integration test fixtures: sample apps containing Windows binaries used to validate end-to-end staging and running on Windows cells.

After removal, the buildpack will only detect and stage apps targeting Linux stacks (e.g. `cflinuxfs4`). Operators with Windows workloads that ship plain executables will need to pin to `v1.1.21` or fork.

## Proposal

- Designate [`v1.1.21`](https://github.com/cloudfoundry/binary-buildpack-release/releases/tag/v1.1.21) as the final release with Windows support. It will receive no further updates, including security patches, for the Windows stack.
- Immediately (no transition period) remove all Windows-specific code, CI, and packaging from [`binary-buildpack`](https://github.com/cloudfoundry/binary-buildpack) and `binary-buildpack-release`, and cut a Linux-only `v2.0.0`.
- Add deprecation notices to repos' `README.md`, CF documentation, and announce on `#buildpacks` Slack.
- Affected users may pin to `v1.1.21` or self-maintain a fork.
## Rationale and Alternatives

- Why immediate removal (no 6-month transition)?
- The Windows code path is already de-facto unmaintained and a transition period changes nothing operationally, since no fixes are being produced anyway.
- Continuing to publish Windows artifacts during a grace period creates a false impression of support and prolongs security risk.
- `v1.1.21` remains available for any operator who needs to keep using Windows, where pinning is a one-line change.
- Sustainability & security: maintainers cannot credibly support a platform they have no expertise on. Additionally, an explicitly removed path is safer than a quietly unmaintained one.
- Alternatives considered:
- Find new maintainers — attempted, none came forward.
- Do nothing — leaves users without patches or clarity.

## Implementation

1. Announce deprecation and removal.
2. Strip all Windows-specific code.
4. Cut a Linux-only `v2.0.0` of `binary-buildpack-release`.
5. Update CF documentation to reference `v1.1.21` as the last Windows-supporting release.