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?
> 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?
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
