Re: [dpdk-dev] [PATCH v6] meter: provide experimental alias of API for old apps

From: Thomas Monjalon <thomas@monjalon.net>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>,
	Eelco Chaudron <echaudro@redhat.com>,
	dev@dpdk.org, David Marchand <david.marchand@redhat.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	Luca Boccassi <bluca@debian.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Stokes, Ian" <ian.stokes@intel.com>,
	Andrzej Ostruszka <amo@semihalf.com>,
	"techboard@dpdl.org" <techboard@dpdl.org>
Subject: Re: [dpdk-dev] [PATCH v6] meter: provide experimental alias of API for old apps
Date: Tue, 19 May 2020 16:24:47 +0200	[thread overview]
Message-ID: <2865818.9VTjjQsp5K@thomas> (raw)
In-Reply-To: <BYAPR11MB293544B8CB4215B99EC34637EBB90@BYAPR11MB2935.namprd11.prod.outlook.com>

19/05/2020 15:26, Dumitrescu, Cristian:
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> > 
> > On v20.02 some meter APIs have been matured and symbols moved from
> > EXPERIMENTAL to DPDK_20.0.1 block.
> > 
> > This can break the applications that were using these mentioned APIs on
> > v19.11. Although there is no modification on the APIs and the action is
> > positive and matures the APIs, the affect can be negative to
> > applications.
> > 
> > This patch provides aliasing by duplicating the existing and versioned
> > symbols as experimental.
> > 
> > Since symbols moved from DPDK_20.0.1 to DPDK_21 block in the v20.05, the
> > aliasing done between EXPERIMENTAL and DPDK_21.
> > 
> > With DPDK_21 ABI (DPDK v20.11) all aliasing will be removed and only
> > stable version of the APIs will remain.
> > 
> > Fixes: 30512af820fe ("meter: remove experimental flag from RFC4115 trTCM
> > API")
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> 
> Thanks, Ferruh and Ray!
> 
> I am OK to let this is temporarily until release 20.11.

Applied, thanks

> Regarding the API breakage larger problem,
> this method only fixes the case of experimental APIs transitioning
> to non-experimental status with no modifications,

Yes

> but it does not handle the following possible cases:
> 
> 	1. Experimental APIs transitioning to non-experimental status with some modifications.

If there is a modification, it should mature as experimental first.

> 	2. Experimental APIs being removed.

No guarantee that an experimental API remains forever.

> 	3. Non-experimental APIs transitioning to deprecated status.

I don't think we need to deprecate experimental API.
We can change or remove them freely at any time.

> We need a clear procedure & timing for all these cases
> to avoid similar situations in the future.
> Likely a good topic for techboard discussion.

We can ask if there are different opinions.
I think the experimental status is quite clear: no guarantee.