On 06/19/17 17:32, Peter Dimov via Boost wrote:
Releasing separately from Boost means that you now have two Boost versions to communicate: the version of Boost.Python, and the version of the preinstalled Boost against which it was built (I built, f.ex. libboost-python-1.65.0-1.53.0 in my CentOS 7 case.)
This consequently affects your downstream dependencies, which also have to include these two versions, in addition to their own. So when a library X depends on Boost.Python and it's compiled against Boost.Python 1.65.0-1.53.0, its version would now be X-1.17-1.65.0-1.53.0. This is not compatible with Y-2.1-1.63.0-1.53.0, even though both are built in the same CentOS 7 environment.
I think, you unnecessarilly complicate things. Yes, naturally lower level dependencies define the effective set of software that is required for the upper level software to build, run and be tested. But it doesn't mean those dependencies need to be reflected in version numbers (they don't) or that the upper level software doesn't work with different versions of the dependencies. Normally, when you release a piece of software, you declare the minimum versions of the prerequisites - preferably, the oldest versions that were successfully tested. IMHO, formal dependency management is a task related to packaging, which is specific to the packaging system. I don't think Boost should be doing this work beyond documenting the dependencies. Let packagers deal with the technical part of enforcing these dependencies with the means they have in their disposal.