On 19.05.2015 01:29, Stefan Seefeld wrote:
On 18/05/15 02:56 AM, Vladimir Prus wrote:
On 5/17/2015 4:08 AM, Stefan Seefeld wrote:
Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime).
Stefan,
could we start by agreeing that not every set of C++-level components will actually benefit, in a cost/benefit sense, from separate development and release? Say, Qt has a few libraries, but has monolithic release. It might be possible to permit QtGui 5.N+1 to work with QtCore 5.N, but the effort and alternative cost of doing so would greatly exceed any benefit.
Sure, fair enough.
Good, thanks!
If we agree on that, then maybe it would be better to propose specific boost libraries that should be released individually, do that, and see whether users appreciate the benefit? That seems more practical than a blanket statement about all boost libraries.
OK, that's a good suggestion. So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on.
Any thoughts on that ?
That's certainly sufficiently local in scope that it could be done. The only concern is that I'm not sure there are many users who need very current Boost.Python, and older Boost. Do you feel there is a demand? Or it's merely that you'll find it more convenient for yourself? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com