Agree. I vote for 2 releases for deprecated features before it is removed 

On Wed, Jun 12, 2019 at 3:07 PM Samuel Ortiz <sameo@linux.intel.com> wrote:
Hi Eric,

On Tue, Jun 11, 2019 at 07:57:14PM +0000, Ernst, Eric wrote:
> Hey cloudy-virt-buds –
>
> We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model.
>
> In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least performant and a bit more complex than necessary.  We recommend end-users utilize tc-filter (default) or macvtap.
>
> Zhang Wei brought up the concern of whether end-users could be using bridge today.  I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change.
>
I don't consider this being a breaking change, but we need to define a
deprecation period for this kind of features. For example we declare it a
deprecated feature now, which means we'd officially (to be documented)
support it for 2 more release cycles.
Obviously this is something that could apply to any other feature we'd
like to deprecate.

Cheers,
Samuel.


_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev


--
Xu Wang
Senior Staff Engineer at AntFin
A member of Kata Containers project
github/twitter/wechat: @gnawux