I don't agree with the claim that we didn't introduce major breaking changes in the past - we did. Routinely.
`cf-release` was sem-ver only insofar as every version was a major version. Changes just as dramatic as this were made on some but not all arbitrary major releases.
The major thing cf-d brings here is real semver, so it's _clear_ that some versions are major changes.
The credo remains the same - forward, always.
Chip's point about long-term support/backported fixes is exactly on-point. It's a major support burden, and is one of the principle pieces of work done by commercial distributors.
Jesse Alford _Formerly of_ CF Release Integration
On Wed, Jul 18, 2018 at 11:38 AM Chip Childers < cchilders@...> wrote: Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the responsibility of the downstream commercial distributions.
This isn't to say that there isn't a solution that can help all downstream users (including non-commercial users AND the distros), yet not burden the Rel Int team too much. I'm not sure what that solution is though...
I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even
if it’s just in appearance (seeing monthly major releases of a product may cause new organizations to hesitate to migrate, until the release process appears more stable.
Dear Josh,
Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would rather have done it
this way – please correct me here if I'm wrong:
-
integrate networking release 2.0 into cf-deployment,
-
integrate other PRs with breaking changes
-
bumping cf-deployment to a new major version, given above changes
-
merging the CVE fixes only into the new major version of cf-deployment
With this process, you would have achieved the following:
-
the development teams are happy, because they shipped as soon as they were ready to
-
operators are grumpy, because they have to bump networking to a new major version and adopt to other breaking changes in order to fix CVEs
I'm not saying you have to turn this tradeoff the other way around, but in my opinion this doesn't seem very consumer friendly.
In your team's mission, you have clearly stated that your goal is to enable development teams to maintain a high velocity. I'd like to stress that we shouldn't leave the operators and users
out of the picture here. In the end, you're developing for them, not for yourself.
I'm not sure if the consumer/operator persona is a thing for RelInt, but if that's the case, here's something I'd like to hold true for whatever change RelInt makes to their process:
"As an operator of CF, I'd like to consume CVE fixes with as little changes to my existing installation as possible, such that I close known vulnerabilities as soon as possible"
Does that sound reasonable?
Hi Marco,
I'm happy to provide more context on the container networking 2.0 reference.
The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0.
RelInt deferred the container networking team's PR for a few weeks due to competing priorities including multiple CVE's fixes.
During the deferral time, a few other PRs were submitted which included breaking changes.
These additional changes took much more time to integrate and validate than anticipated and in the end, the container networking team's 2.0 release was published in cf-d about 5 weeks after it was ready to go.
The introduction of a regular cadence aims to mitigate this type of delay in the future. Had we had one at the time, the networking team would have timed it's PR to align and we would have been poised to accept and publish it quickly.
We believe this will help teams confidently plan for, communicate about, and negotiate integrating their releases into cf-deployment.
And hopefully enable the RelInt team to integrate and ship major releases more seamlessly.
This is an evolving process so we'll see how things roll in the coming months and make adjustments where it makes sense to do so.
I appreciate and welcome any and all feedback along the way.
Thanks very much,
Josh
|
