On Fri, Apr 17, 2020 at 08:24:30AM +0100, Ray Kinsella wrote:
>
>
> On 16/04/2020 11:01, Thomas Monjalon wrote:
> > 16/04/2020 11:51, Bruce Richardson:
> >> On Wed, Apr 15, 2020 at 06:24:19PM +0100, Trahe, Fiona wrote:
> >>> 5a. If in 20.05 we add a version of a fn which breaks ABI 20.0, what
> >>> should the name of the original function be? fn_v20, or fn_v20.0
> >>
> >> In technical terms it really doesn't matter, it's just a name that will be
> >> looked up in a table. I don't think we strictly enforce the naming, so
> >> whatever is clearest is best. I'd suggest the former.
> >
> > Each release can have a new ABI.
>
> How many ABI's do we want to support?
>
It's not how many we want to support, but for me it's a matter of how many
do we need to support. If an API is part of the stable set, it can't just
drop to being experimental for one or two releases - it's always stable
until deprecated. We also shouldn't have a situation where release 20.08 is
ABI compatible with 19.11 but not 20.02 and 20.05.
> > The same function can have a different version in 20.02, 20.05 and 20.08.
> > If you name it fn_v20 in 20.05, what will be the name for the new version
> > in 20.08? I suggest using the release number when versioning a function.
> >
>
> ok - so this is exactly _not_ what we wanted at the outset.
>
> We committed to support a single ABI, that is the 19.11 (v20) ABI until the
> 20.11 (v21) ABI.
> We do _not_ support ABI stability in quarterly releases, as the support
> overhead would balloon overtime.
>
> Really why would we do this - who would benefit?
>
> Do we envisage a situation that someone who built against the say 20.02
> shared libraries.
> would expect their binaries to port to 20.05 without a rebuild?
>
I would have expected that, yes, as all have the v20 ABI.
Maybe I need to change my expectations, though.
/Bruce
> It would also defeat the purpose of EXPERIMENTAL, if the community where
> willing to support any permutation of an API.
> Why would ever bother to use experimental?
>
> I have a bit more checking to do, but IMHO the following we should fix the
> following commits such that APIs are either EXPERIMENTAL or staged for v21.
>
> r...@ashroe.eu:/build/dpdk# find . -name *.map | xargs grep 20.0.1
> ./lib/librte_meter/rte_meter_version.map:DPDK_20.0.1 {
> ./drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map:DPDK_20.0.1 {
> ./drivers/net/ionic/rte_pmd_ionic_version.map:DPDK_20.0.1 {
> ./drivers/common/octeontx2/rte_common_octeontx2_version.map:DPDK_20.0.1 {
> ./drivers/common/mlx5/rte_common_mlx5_version.map:DPDK_20.0.1 {
> ./drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map:DPDK_20.0.1 {
>
> Thanks,
>
> Ray K
>
>
