Hello cf-dev,

We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team.

What?

The goals of the team are to:

• Complete the v3 CC API and deprecate the v2 CC API

• Introduce a new major CLI release which will be backed by the v3 CC api

• Deprecate both the v2 CC API and the v6.x.x CLI in a sustainable, and orderly manner - taking into account support policies and giving as much buffer as possible so that the Community can make the transition seamlessly.

Why?

New API features are currently being developed on the v3 CC API, which introduced new features including running tasks, defining app processes via a Procfile, and granular control of an application lifecycle.

The development teams are happy with the API interface as well as the changes in underlying implementation of the v3 CC API. Given the desire to implement all new features in the v3 CC API, it is now necessary to complete moving the rest of the existing v2 CC API over to v3.

To expose the v3 api to end users, the CLI team implemented v3 prefixed commands in CLI release v6.32.0; and in CLI release v6.38.0, we updated the `cf app` to use the v3 endpoint.

However, whilst working toward this v3 effort, both the CAPI and CLI teams came to the realization that development work for the v3 api, and the CLI's adoption of it, is best done as a dual effort for a number of reasons:

• in the v3 api, the very definition of an app has changed. Instead of being defined by the instance, in v3, an app is defined by its process. This has implications for how you interact with an app from the CLI perspective: from pushing an app, to scaling it, to setting its health checks - it is now done by process type, not instance type.

• the feedback process would be greatly enhanced for both products if development work is done in lockstep as both the CC API and the CLI introduces changes and product enhancements to our users

• we plan on introducing new beta major releases of the CLI which will only be compatible with the latest CC API release, and will not be backwards compatible - we will only support the latest version of the beta release. This allows us to expose new features of the v3 endpoints and to redefine some of the interface in a sustainable manner. Once the beta releases are backed completely by the v3 api, and we've incorporated your feedback sufficiently, we will GA a major release of the CLI.  It's important to note that the v6 CLI will continue to be a separate team, and they will continue to maintain the v6 CLI including releasing bug fixes, CVEs, and a limited number of new features

Please let us know if you have any questions or concerns about this approach; you can find us on slack at #v3-acceleration-team. We are also at CF Summit on October 11th: office hours at 11:15am (Lounge 1, The Foundry for the CF CLI and Lounge 2, The Foundry for CAPI).

Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead

Hi Zach,

Some feedback related to the deprecation of the CC API V2 in favor of V3: there are many tooling out there that currently rely on the CC API V2 (such as UIs, service brokers, provisionning tools such as terraform-provider-cf or SAP MTA...). These tooling usually leverage CC API clients [2]. Ways to reduce impacts for such tooling would be to work with client maintainers (both official, experimental and unsupported) so sync the CC API V2 support policy with availability of CC API V3 support in clients is most widely used programming languages.

The terraform-provider-cf [1]  in particular is quite interested in having the CF CLI CC API client being extracted into a distinct repo, and be more developer friendly, see related discussions in [3][4]. Part of the terraform-provider-team will be at basel summit (see related talk at [1b]) and would be eager to exchange with the CF CLI team on this topic, possibly during the CF CLI office hours.

Thanks,

Guillaume.

[1] https://github.com/mevansam/terraform-provider-cf/

[1b] https://sched.co/FRyl

[2] https://docs.cloudfoundry.org/devguide/capi/client-libraries.html

[3] https://github.com/mevansam/terraform-provider-cf/issues/56#issuecomment-410952359

[4] https://github.com/mevansam/terraform-provider-cf/issues/120

On Tue, Oct 2, 2018 at 6:46 PM Zach Robinson <zrobinson@...> wrote:

Hello cf-dev,

We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team.

What?

The goals of the team are to:

• Complete the v3 CC API and deprecate the v2 CC API

• Introduce a new major CLI release which will be backed by the v3 CC api

• Deprecate both the v2 CC API and the v6.x.x CLI in a sustainable, and orderly manner - taking into account support policies and giving as much buffer as possible so that the Community can make the transition seamlessly.

Why?

New API features are currently being developed on the v3 CC API, which introduced new features including running tasks, defining app processes via a Procfile, and granular control of an application lifecycle.

The development teams are happy with the API interface as well as the changes in underlying implementation of the v3 CC API. Given the desire to implement all new features in the v3 CC API, it is now necessary to complete moving the rest of the existing v2 CC API over to v3.

To expose the v3 api to end users, the CLI team implemented v3 prefixed commands in CLI release v6.32.0; and in CLI release v6.38.0, we updated the `cf app` to use the v3 endpoint.

However, whilst working toward this v3 effort, both the CAPI and CLI teams came to the realization that development work for the v3 api, and the CLI's adoption of it, is best done as a dual effort for a number of reasons:

• in the v3 api, the very definition of an app has changed. Instead of being defined by the instance, in v3, an app is defined by its process. This has implications for how you interact with an app from the CLI perspective: from pushing an app, to scaling it, to setting its health checks - it is now done by process type, not instance type.

• the feedback process would be greatly enhanced for both products if development work is done in lockstep as both the CC API and the CLI introduces changes and product enhancements to our users

• we plan on introducing new beta major releases of the CLI which will only be compatible with the latest CC API release, and will not be backwards compatible - we will only support the latest version of the beta release. This allows us to expose new features of the v3 endpoints and to redefine some of the interface in a sustainable manner. Once the beta releases are backed completely by the v3 api, and we've incorporated your feedback sufficiently, we will GA a major release of the CLI.  It's important to note that the v6 CLI will continue to be a separate team, and they will continue to maintain the v6 CLI including releasing bug fixes, CVEs, and a limited number of new features

Please let us know if you have any questions or concerns about this approach; you can find us on slack at #v3-acceleration-team. We are also at CF Summit on October 11th: office hours at 11:15am (Lounge 1, The Foundry for the CF CLI and Lounge 2, The Foundry for CAPI).

Thanks,
Zach Robinson CAPI Project Lead and Abby Chau CLI Project Lead