I'm replying to this as someone who has used the old and new versions of Boost Process API. And migrated code (not hard) to the new API. And left code that I haven't had reason to update, using the old version of Boost, with the old API. On Thu, 31 July 2025, 8:36 pm Artyom Beilis via Boost, < boost@lists.boost.org> wrote:
On Thu, Jul 31, 2025 at 12:40 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Wed, Jul 30, 2025 at 11:54 PM Artyom Beilis via Boost <
boost@lists.boost.org> wrote:
I write the code down and... it wouldn't compile... Ok look at the latest API it changed. Deep down it happened at v1.86 about a year ago.
The tendency for a library's API to break will vary, as each Boost library has its own set of authors and/or maintainers.
Thanks
Yes, this is why policies are useful.
Boost has 1001 difference policies and restrictions on libraries but 0 requirements on any kind of compatibility/stability.
This is good. It lets the user chose (to stay in an old version or pick a newer one). I trust Boost authors not to gratuitously change APIs.
These kinds of issues must be addressed by policies and management of something like a Long Term Support version that would keep the API stable for at least several years.
A policy won't force a volunteer author or maintainer to provide support for anything, especially not an API said author considers flawed. If you want paid (so one might expect, policy conforming) support for stable APIs I can recommend some vendors that give me far more expensive headaches than Boost does. Or you can, as I do, carry the cost of managing versions / update policy regarding use of Boost libraries yourself. Just another perspective as a long term Boost user. As always, YMMV. Darryl.