Hello, We’re currently evaluating the impact of continuing to use an older version of Boost by reviewing fixes and changes introduced in later versions. While our application has several direct dependencies, the bcp tool reveals that we also pull in dozens of indirect (transitive) dependencies.
Ideally, we’d like to limit our review to the release notes and fixes for the direct dependencies—focusing on how our application uses those modules directly. However, we’re concerned about missing issues in secondary dependencies that could affect the behavior of the primary modules we depend on. For example: Our application uses moduleA, which internally includes moduleB. If moduleB had a memory leak that was fixed in a later release, how can we determine whether moduleA was impacted by that issue - and whether our application was indirectly affected? Questions: Is there an efficient way to identify whether such secondary dependency issues have a downstream impact on the primary modules? That is, without deep diving into both moduleA and moduleB code bases and seeing if the issues/fixes apply. Are there any Boost policies or guidelines stating whether maintainers of a primary module are expected to review and address issues in their transitive dependencies? Any insights or suggestions would be greatly appreciated. Thanks, Joe _______________________________________________ Boost-users mailing list -- boost-users@lists.boost.org To unsubscribe send an email to boost-users-le...@lists.boost.org https://lists.boost.org/mailman3/lists/boost-users.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost-users@lists.boost.org/message/LNFRF5Q2RKU5TS4WA5OXH6ECYV4L7NDP/
