The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.

With that, I'm not in product management but, in my opinion, the definition
of "done" and "ready" are relative.

The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.

That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.

As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.

Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.

So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].

[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287

--
Matthew Sykes
matthew.sykes(a)gmail.com