Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Hi Robert,
IIUC, your strategy to tests has some advantages, but it has some liabilities also:
* every developer should use the same strategy,
This is not the case I believe. You can opt to use whatever strategy you want. If you develop library A and it depend on library B you can: * depend on trunk version of B: A.deps = B:TRUNK This way you get notified as soon as any changes in dependent library occurred and more importantly if they causing a conflict with A * depend on latest released version of B: A.deps = B:LATEST This way you know when something breaks as soon as B is released and you and/or library B developer can arrange for correct resolution at that time * depend on specific version of B: A.deps = B:1.50 This way you never need to worry about B changes, but you will get in trouble if new version of B is released. In this case released version of A is not usable anymore with released boost package. We can use this mode for deprecated libraries, which we may not wont to remove from release immediately.
* the trunk will surely be broken as no one is testing with the trunk of the others libraries,
There will not be a "boost trunk". Each library has it's own trunk. And each of these trunks will work/test fine if dependency rules are set correctly.
* it delays the day conflicts are evident to the day the developer merges to release, as no one has tested with the new changes.
This is not necessarily a bad thing: * It allow to delay conflict resolution to the time when B is stable and only things which remains unresolved is conflict with A * It does not require library A and B developers to be in sync time-wise. There are two scenarios: = Either library A developer at the time when he or she is ready to make a release will run a full test of boost with B's LATEST replaced with TRUNK (we need to have a way to do this), find out about all conflicts and resolve. After that B can be released and we should not expect many problems (aside of potential race conditions) = Either library A developer wants to use TRUNK version of B. He or She runs the test against B:TRUNK find out all conflicts resolve them either by changing A's code or y communicating the issue to the B library developer and fixing it there. After that B need to go through the step above to ensure that there is no other conflicts (unless A is the only user of B). This can be initiated by library A developer. B is released and A can now depend on B:LATEST. Alternatively A's developer can encourage B's developer to make a release (see above) and meanwhile continue to develop against TRUNK version of B, by setting a dependency on B:TRUNK
I think the authors of the Boost libraries should try to avoid the introduction of breaking changes. Breaking changes should be manage
I believe correct statement is boost author should avoid releasing of breaking changes. If one need to run a test with some potentially breaking changes ( even just to be able to see if they are breaking or not or because these are new interfaces and backward compatibility is not implemented yet or because one wants to create ea special version which is intended to be used by some other library C)
using versions and deprecated periods. If this were the case, new features could be added in trunk without any problem, and the authors could have enough time to move to the new breaking ones. Even when we will have a modularized Boost, we should manage with breaking changes in the same way (versions and deprecated periods).
I do not believe breaking changes is such a big/widespread problem among boost libraries. BAU platform differences, errors and small oversights are much more common. Regards, Gennadiy