How long will 1.x, and 2.x cf-deployments be maintained with security patches? Without that, it sounds like there’s potential for a lot of organizations to be faced with breaking changes
and instability every time they upgrade (if upgrade cycles internally take a month or two, and major versions are coming out as often or more), not to mention the difficulties of jumping multiple major versions at once.
From: <cf-dev@...> on behalf of Josh Collins <jcollins@...> Reply-To: "cf-dev@..." <cf-dev@...> Date: Tuesday, July 3, 2018 at 6:16 PM To: cf-eng <cf-eng@...>, cf-pm <cf-pm@...>, "cf-dev@..." <cf-dev@...>, CF Dev <cf-dev-eng@...> Subject: [External] [cf-dev] cf-deployment 3.0
Hey Y'all,
Cf-deployment 3.0 is around the corner.
We're going to go 3.0 in 2-3 weeks.
We released cf-deployment 2.0 on June 18th and included 'breaking' changes.
Breaking changes in the context of cf-d are changes which would require special attention from operators for the deployment to succeed. Executing the same bosh deploy command/args run used in the previous deployment may fail depending on
which ops files and features operators had deployed with in the past.
Going forward, we'd like to introduce a more regular (~monthly) cadence to major point releases of cf-deployment.
The goal is two-fold and in-order-of-importance:
provide a reliable mechanism for cf component teams to integrate and release major changes
mitigate fear of major point releases in the minds of operators/cf-consumers
As of today, we've got one PR that includes breaking changes and I'm putting out a call to y'all.
If you've got what you'd consider to be a breaking change that warrants going out in a major point release of cf-deployment, please submit your PRs and reach out to the RelInt team as soon as you're able to so we can come up to speed and
support you!
