Hi, Please find the techboard comments below. 06/11/2019 10:22, Ray Kinsella: > On 06/11/2019 09:06, Thomas Monjalon wrote: > > 06/11/2019 09:49, Ray Kinsella: > >> On 06/11/2019 00:11, Thomas Monjalon wrote: > >>> 05/11/2019 16:24, Ray Kinsella: > >>>> +#. Major ABI versions are declared every **year** and are then > >>>> supported for one > >>>> + year, typically aligned with the :ref:`LTS release > >>>> <stable_lts_releases>`. > >>> > >>> As discussed earlier, a major ABI version can be declared less often > >>> than one year in the future. > >>> An ABI is supported more than one year, because of the LTS branches. > >>> That's why I propose to replace with this sentence: > >>> " > >>> Major ABI versions are declared regularly and are then supported for > >>> at least one year, typically aligned with the :ref:`LTS release > >>> <stable_lts_releases>`. > >>> " > >> > >> So look, this one was a decision of the technical board. > > > > The techboard didn't decide to change the ABI every year. > > We decided to review the duration after the first year, with a plan to > > extend. > > > >> My position is still what was agreed was, "declared every year, and > >> supported for one year". > >> I like it, it's crystal clear what is the policy, until we change the > >> policy. > > > > I think it gives a wrong message. > > > >> That said, I can make the change no problem, but I need some others to > >> chime in to ok it. > >> Perhaps at the head of the Techboard today? > > > > Yes I add it to the techboard meeting.
The techboard propose other rewords: "supported" may be replaced with "compatibility is enforced" "every year" may be replaced with "no more frequently than every year" "declared" may be replaced with "could be declared" I think you got the idea. Please adjust wording to something more accurate. ### > >>>> +A major ABI version is declared every year, aligned with that year's LTS > >>>> +release, e.g. v19.11. This ABI version is then supported for one year > >>>> by all > >>>> +subsequent releases within that time period, until the next LTS > >>>> release, e.g. > >>>> +v20.11. > >>> > >>> Let's reword like this: > >>> " > >>> A new major ABI version can be declared when a new LTS branch is started, It has been suggested to replace "can" with "may". > >>> e.g. ABI 19 for DPDK 19.11.0. > >>> This major ABI version is then supported until the next one, > >>> e.g. ABI 20 for DPDK 20.11.0. > >>> All ABI changes must be detailed in the release notes. > >>> " My reword is wrong because ABI versions should be 20 and 21 respectively. > >> This is more ambiguous, although what I said above stands. > > > > What you said is wrong because of 2 reasons: > > - it is not always one year for an major ABI > > Well that is a point of disagreement. The techboard agreed to remove "every year". > > > - it is always longer because of LTS branch > > Well I was pretty careful to qualify the ABI policy applies to releases over > the year. > To distinguish it from LTS branch. As above, we may replace "ABI is supported" with "ABI compatibility is enforced". > >> If there is general agreement with changing this part of the policy, I am > >> ok to make > >> the change. > > > > Yes let's review with the techboard. Please try to reflect techboard comments while keeping something understandable :) ### > >>>> + ABI breakages due to changes such as reorganizing public > >>>> + structure fields for aesthetic or readability purposes should be > >>>> avoided. > >>> > >>> Why it should be avoided? > >>> If the ABI is broken anyway, I don't see any reason to not break it more. > >> > >> This is text from the original ABI Policy - I think the general sentiment > >> still stands. > >> Just because you have an ABI Breakage window doesn't mean you should feel > >> free to break > >> the ABI. The 3 ACKs required from Technical Board member to change the > >> ABI, are another > >> reflection of this. > >> > >> As a general rule. > >> Unnecessary changes should still be avoided, to reduce ABI churn between > >> ABI versions. > > > > I agree we must avoid unnecessary API changes because it requires apps to > > adapt. > > But if the change is only ABI, and we are in an ABI-change window, > > I don't see any issue The techboard agrees that the ABI changes are unlimited but API changes must be avoided. It is suggested to replace "ABI" with "API". I think this reword is better: " API changes such as reorganizing public structure fields for aesthetic or readability purposes should be avoided. " ### > >>>> +Libraries marked as ``experimental`` are entirely not considered part > >>>> of an ABI > >>>> +version, and may change without warning at any time. Experimental > >>>> libraries > >>>> +always have a major version of ``0`` to indicate they exist outside of > >>>> +ABI Versioning, with the minor version incremented with each ABI change > >>>> +to library. > >>> > >>> It means not all libraries will have the same ABI version. > >>> It is contrary of "ABI version is managed at a project level", > >>> and I don't see a real benefit of a different version number. > >> > >> There is a benefit, major version 0 is a very clear indication that > >> the library exists outside of ABI management. > >> A library isn't in the ABI, until it is in the ABI - an then it gets > >> added to the major version number. > >> > >>> Anyway, some experimental functions can live inside a library > >>> with a stable ABI version number > >> > >> True, but if an entire library is experimental - let's be crystal > >> clear about that. > > > > I would like to see what others think. The techboard decided to keep this policy: .0 for pure experimental libs.
