Can you point to concrete projects where that has been a problem? As it's hard to discuss these things in the abstract.
Ok... Here is an example I encountered just yesterday. I needed to provide a fork/exec/kill/wait alternative for Windows... I know the boost proces - Ok - header only library - fantastic. Until now my project didn't use boost so I get the latest version. So quick google (and their gemeni) leads to examples exactly what I need: bp::child, wait, terminate, wait_for etc. Lots of tutorials fine. 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. But not a simple change - wipe out an old API and create a new API... Not add (bp::process) - remove child and replace it with process! If I was using the boost process in the first place when I started the project instead of fork/exec and then later ported it to windows I would discover that the code stopped working with the latest release. More than that most linux distros wouldn't even ship 1.86 so I need either require a specific boost version or tell use the old one. No grace time, no deprecation, no keeping old API for a while (replacing headers with v1 is not backward compatibility it is a workaround) And honestly including huge dependency on Boost.Asio without "asking" is a problem. It just reminded me why I avoid using Boost in my own projects! If I had been using Boost.Process it would break while porting to Windows. And I ended up skipping on the Boost once again instead of using boost.process I just kept my fork/exec/kill/wait code and added win32 version of CreateProcess/Terminate/GetExistStatus - it was way simpler than deal with multiple APIs. And this isn't my first such experience, it just reminded me why I ditched Boost for my projects in the first place and probably not looking back unless I absolutely must. Artyom