Re: [boost] What Should we do About Boost.Test?

Subject: Re: [boost] What Should we do About Boost.Test?
From: Gennadiy Rozenal (rogeeff_at_[hidden])
Date: 2012-09-19 00:47:18

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