The first release of the Python buildpack after January 1, 2020 will no longer include Python versions 2.7.x. These Python versions will no longer be supported upstream.[1] Please migrate your Python apps to supported versions of Python before that time.

As 2.7.x is the current default for the Python version in the buildpack, the default Python version will be updated to 3.8.x as a part of this removal. If you’d like to use a different Python version, please configure your application to select that version[2]. As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel.

Please note that as miniconda2 depends on Python 2.X, miniconda2 will also be removed as a part of this release. Miniconda3 is currently available in the buildpack.

[1] https://www.python.org/dev/peps/pep-0373/

[2] https://docs.cloudfoundry.org/buildpacks/python/index.html#runtime

Thanks,

Kashyap Vedurmudi, CF Buildpacks PM

The first release of the Node.js buildpack after January 5, 2020 will no longer include Node.js versions 8.x. These Node.js versions will no longer be supported upstream.[1] Please migrate your Node.js apps to supported versions of Node.js before that time.

Note: While the default version of Node.js in the Node.js buildpack is 10.x, it is recommended that you ensure your Node.js applications are not specifying a Node.js version of 8.x in either a buildpack.yml, .nvmrc, or package.json files. As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel.

[1] https://nodejs.org/en/about/releases/

Thanks,

Elliott Shanks, CF Buildpacks PM

The first release of the .NET Core buildpack after January 4, 2020 will no longer include .NET Core versions 2.2.x. These .NET Core versions will no longer be supported upstream.[1] Please migrate your .NET Core apps to supported versions of .NET Core before that time.

Additionally, the default version of .NET Core will change from 2.2.x to 3.1.x at this time.

Note: Unless you are manually specifying a version of .NET Core for the buildpack to use, or you have customized your .NET Core buildpack, no action is required.

[1] https://dotnet.microsoft.com/platform/support/policy/dotnet-core

Thanks,

Elliott Shanks, CF Buildpacks PM

Hello cf-dev!

The cf-k8s-networking team ship a new feature leveraging Istio and Envoy technology that App Developer can rely on the platform to provide http ingress routing to the workload on Cloud Foundry running on Kubernetes details. 

Please reach out if you have any questions. Thanks.

Regards,

TL;DR:

In the coming weeks, the CF Buildpacks team will be releasing a new Node.js buildpack, composed of modular buildpacks, that implements the Cloud Native Buildpacks (CNB) API. This buildpack can be used with any platform that supports CNB.

A buildpack release that contains a compatibility layer for use on the Cloud Foundry Application Runtime can be found in the nodejs-cnb repo. Add the buildpack to your list of buildpacks and `cf push` to begin building Node.js applications with the new Node.js buildpack.

Introduction to new buildpacks

Over the past year, the buildpacks team has worked to build the next set of Cloud Foundry buildpacks using the Cloud Native Buildpacks (CNB) API. In the coming weeks, we will be releasing the Node.js CNB. This new buildpack is compatible with any CNB platform (such as the pack CLI or kpack) and additionally contains a limited compatibility layer for the Cloud Foundry Application Runtime. (Note that the compatibility layer produces a droplet, while CNB platforms output special, rebasable OCI images.)

What are Cloud Native Buildpacks?

Cloud Native Buildpacks, a CNCF sandbox project, uses a modular approach to building applications by splitting major dependencies and operations on applications into their own dedicated CNBs. What was once the Node.js buildpack is now a combination of the node-engine, yarn, and npm CNBs. This allows for a transparent build process that is easier to debug when a build fails. CNB also employs better caching and data deduplication, and as a result, faster builds and faster deploys on platforms that support OCI images. 

Note: Due to the modular nature of CNB, the new Node.js buildpack does not currently include certain external integration helpers, such as those for APM agents. It has been difficult to manage and test these integrations, and we plan to shift towards modular integration CNBs that are maintained outside the project by integration authors and platform vendors.

Using CNBs on Cloud Foundry Application Runtime

To use the new Node.js CNB, it is as simple as grabbing the shimmed release artifact from the nodejs-cnb repo and adding the buildpack to your list of buildpacks on your foundation. 

Note: Because the CNB API results in an OCI image, a compatibility (shim) is required in order to translate the new Cloud Native Buildpacks API to the existing CF Buildpack API. This compatibility layer is less performant than CNB, but fully supports CF multi-buildpack mode when multiple CNBs are specified, by translating it to CNB’s native modular buildpack mode. Additionally, it provides compatibility with older supply-only CF buildpacks, as long as those buildpacks precede the CNBs.

To add the new buildpack to CFAR:

cf create-buildpack <buildpack-name> <path/to/downloaded_shimmed_nodejs_buildpack> <detection order>

If you want to cf push without -b <buildpack-name> use a <detection order> number smaller than the current Node.js buildpack detection order number during `create-buildpack`. To see the detection order of buildpacks run `cf buildpacks`.

Ways to Provide Feedback

The buildpacks team would love to gather feedback from the CF community about your experience using the Node.js CNB when it is released. As always, you can drop into the Cloud Foundry slack in the #buildpacks channel to reach out. 

We hope that you are as excited as we are about the new future of buildpacks.

Respectfully,

CF Buildpacks Team