On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases for deprecating the signal flavor: 1) liburcu-signal will be implemented in term of liburcu-mb. The only difference between the two flavors will be the public header files, linked symbols and library name. Note that this add a regression in term of performance, since the implementation of liburcu-mb adds memory barriers on the reader side which are not present in the original liburcu-signal implementation. 2) Adding the deprecated attribute to every public functions exposed by the liburcu-signal flavor. At this point, tests for liburcu-signal will also be removed from the project. There will be no more support for this flavor. 3) Removing the liburcu-signal flavor completely from the project. Finally, here is a tentative versions release of mine for each phase: 1) 0.15.0 [October 2023] (also TSAN support yay!) 2) 0.15.1 3) 0.16.0 || 1.0.0 (maybe a major bump since this is an API breaking change)
There is a distinction between the version number of the liburcu project (0.14) and the ABI soname for the shared objects. We may be able to do step (3) without going to 1.0.0 (I don't see removal of the urcu-signal flavor a strong enough motivation for hitting 1.0.0 yet).
Technically speaking, given that we would be removing the entire liburcu-signal.so shared object, we would not be changing _symbols_ within an existing shared object, therefore I'm not even sure we need to bump the soname for all the other remaining shared objects.
Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
