Jerome,
<release manager hat on> I agree with Dave’s proposed approach to handling it, with a little more emphasis on reviewing + merging the triplet of prerequisite changes (46747, 46571, 46572) ASAP and having them merged before 26.10-RC1 milestone next Wednesday as a prerequisite of merging 46753 past-RC1. Traditionally our logic with change handling on the API boundaries was to have one release with a given API marked as “deprecated” and then only the next release would remove them. Merging the preparatory changes now and the actual change shortly after RC1 + documenting this in Release Notes will give folks that are tracking VPP at release cadence some time to prepare; For those who are using master, a week or two won’t make a big difference.
The above assumes that we as a community are happy to treat this change in the same vein as API changes. If there are opinions that it should be treated differently - I am open to not merging any of the 4 now and deciding on the policy first, with understanding that it may mean postponing 46753 until past 27.02-rc1 if in the end we agree that the “one release notification window” still does apply.
—a
Hi Jerome,
Thank you for leading the discussion in the last VPP Community
meeting about hidden visibility and for adding the out-of-tree
plugin checker. While I agree with the resolution of all of the
technical issue, I have not seen any feedback on the timing of
merging such a large ABI breaking change or communicating the
change to downstream consumers. There are 40 public downstream
consumers listed on https:/fd.io with most likely 10x the amount
who are privately consuming VPP. There are 23 production
features in libvnet, most of which are affected by this change. We, the FD.io committers,
have a moral obligation to consider the effects of the code being
merged on all of our community members, including communicating
the change, allowing for time feedback and time to plan for
assimilation of major changes like this.
Since you have come to the consensus that hidden visibility be
enabled by default, I will modify my proposal for merging 46573,
its parent changes (46571, 46572) and 46747 as follows:
1. Merge 46747, 46571, 46572 at any time each has been
'Code-review +1' by maintainers and/or committers
2. After VPP 26.10 stable branch has been pulled next Wed
(9/23/26) and gerrit changes 46571, 46572, 46747 have been merged,
then merge 46753
3. Add a note to VPP 26.10 release notes, announcing the ABI
breaking change to libvnet and how to verify out-of-tree plugins
and fix issues found (i.e. add __clib_export to functions/symbols
required by out-of-tree plugins & kindly upstream these
fixes).
4. Conclude the discussion on how/when to provide advance notice
of ABI changes to production features and add documentation
stating the agreed upon process.
Thanks,
-daw-
On 9/9/26 1:25 AM, Jerome Tollet wrote:
Hi Dave,
Following yesterday's VPP Community call, the consensus was to move forward with hidden visibility enabled by default, while providing a build-time option to restore the current visibility behavior.
This option is now implemented in 46573 PS8, the standalone external checker is available in 46747, and the complete series is Verified +1.
Could you please re-review 46573 and remove the Code-Review -2 if you have no remaining technical blocker? If you still see one, please identify it on Gerrit so it can be addressed.
Thanks,
Jerome
|
